Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asynchronously perform database operations on queue, using transactions. #469

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

sunilsharma08
Copy link

Synchronous transaction on queue hangs ui if some insertion/updation is performed on large no of rows.
To avoid ui hang because of synchronous transaction I have added a method named "inTransactionAsync" which perform database operations asynchronously.

@ccgus
Copy link
Owner

ccgus commented Feb 23, 2016

What's the advantage of putting this in FMDB, vs just throwing it in a background block?

(PS- what's the point of the FMDBRetain & FMDBRelease outside the block?)

@robertmryan
Copy link
Collaborator

FWIW, I second the vote that there should be an asynchronous rendition of inTransaction and inDatabase as part of FMDB. If a method can possibly block, it should be asynchronous. Apple has been religiously following this practice in all of their recent APIs and they just don't offer synchronous/blocking methods anymore. To be provocative, I think the question isn't "what's the advantage of putting this in FMDB?", but rather "should we have a synchronous rendition at all?"

My only question (setting aside the FMDatabaseRetain and FMDatabaseRelease issue) is whether this should be part of FMDB 2.x, or whether it should be deferred to FMDB 3.0. It seems to me that this might be better suited for the next major revision of FMDB. I say that because I think a better method name would be performTransaction or something like that. This name follows the verb-noun pattern that we use in APIs nowadays and avoids perpetuating the potential confusion of this FMDatabaseQueue method with the completely unrelated inTransaction method of FMDatabase. But such a major method renaming and/or shift from synchronous to asynchronous probably belongs in a major update, not a minor update.

@ccgus
Copy link
Owner

ccgus commented Feb 23, 2016

I'm actually for an async method as well (as it's planned for 3.0: https://github.com/ccgus/fmdb/blob/three/FUTURE_PLANS.markdown )

I asked the question because I was curious.

3.0 has taken a backseat in my free time lately though. I had hoped to get something going last Dec, but it just didn't happen. Maybe this should be part of 2.x, because I don't know when 3 will happen?

@sunilsharma08
Copy link
Author

What's the advantage of putting this in FMDB, vs just throwing it in a background block?

My intention to add asynchronous method is to provide non blocking database operation even when working with large records.
I just tried to keep the same queue but operation should be performed asynchronously.

(PS- what's the point of the FMDBRetain & FMDBRelease outside the block?)

I put the FMDBRetain & FMDBRelease inside the block in my second commit.

"what's the advantage of putting this in FMDB?", but rather "should we have a synchronous rendition at all?"

It will be more appropriate to give both option to perform database operations either synchronously or asynchronously.Let the developer to choose which one is better for the task.

@ccgus
Copy link
Owner

ccgus commented May 11, 2016

FWIW, I've just added async transactions to the three branch:
https://github.com/ccgus/fmdb/tree/three

Discussion on it here:
#487

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants