ccgus/fmdb — Issue #47: An "async" version of "inTransaction:" ? + a design question
Author: SoftTenebrasLux
Created: 2012-02-22 14:24:54+00:00
State: open

Hi.
I was about to implement the FMDatabaseQueue stuff myself before I discovered it's just been added to fmdb.
But I see all the transactions are done with a "dispatch_sync" which doesn't return until all the stuff is made.

In my code I would need an "async" version of it. That is, schedule the block to the serial queue, and move on immediately. The crucial point is the serial nature of the queue to avoid multi-threaded collisions. But not the way you schedule blocks to it.

The implementation of the async version could virtually be identical to the sync one, apart from the dispatch function, and the absence of need to make a retain/release (for non-arc code), since a Block_copy() is made in dispatch_aync.

To the contrary of the sync version however, there could be some difficulties if you need to perform some actions once the block is done on success, or when it has failed. We can imagine other block arguments, that could be performed on the main global queue (just a suggestion) after the rollback / commit.

Also, I wonder the meaning of passing "db" as an argument of the block of transactions, and always calling [self database] inside the method implementation. What happens if they are different?

The example given in the README of fmdb is confusing. Imagine you have another "FMDatabase" called db2. Nothing prevent you to write (it's a mistake I agree), inside the "inTransaction" block: "[db2 executeUpdate:...]". Then the whole transaction is meaningless.

In fact, to me, the "inTransaction" method should be a method of the FMDatabase instance itself. In fact, instead of a new class FMDatabaseQueue, every "standard" update and query should be done on the underlying serial queue in the FMDatabaseInstance, and then the whole FMDB lib would be thread-safe thanks to GDB.

My 2-cents.