Hi list, I'm looking for the right design pattern for providing different types of access to an SQLite database.
Currently I have a database object where queries are run on a serial NSOperationQueue and each operation has a completion block for reporting its results. The operation queue is an implementation detail behind a more basic API. This is fine for most things, except that I sometimes need faster access to the underlying database - for example, when importing/exporting data. In these cases I'm after bulk data throughput without the overhead of creating/destroying many NSOperations with completion handlers since there can be in the order of millions of statements to handle. In the past I had simply broken encapsulation by exposing the underlying database engine API. I'd rather find a better method than this for the future. Options considered so far: 1. Continue exposing underlying DB engine 2. Add a simpler synchronous API for use on a separate thread 3. Expose NSOperationQueue and allow custom import operations to be queued 4. Add importing functions to the database object itself Does anyone have any suggestions as to how best to approach this problem? - Ben _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
