I am sure that you are correct, that Sqlite's sync mechanism is not
terribly complicated for you and for anyone else who understands the
principles, however it does confuse many users as you see from the
posts to this forum. Simple to use could become simpler to use.
Synchronizing transactions is not intricate, particularly when it is
achieved transparently to the application programmer by the Sqlite
application support layer.
Trevor Talbot wrote:
The thing is, SQLite's synchronization mechanism is simpler than most
full-featured SQL databases. In all cases, the point is that if you
are attempting to do simultaneous writes from two connections, each
connection must be prepared to receive an error, rollback the
transaction, and try again.
Personally, I don't see anything terribly complicated about that.
Concerning yourself with the intricate details in order to get the
best performance is complicated, sure, but the basic principle isn't.
You have to do error checking anyway, the only difference is that it
may affect your entire transaction rather than just one statement.
That's true for working with SQL databases in general.
For those applications don't want parallel access at all, SQLite
provides BEGIN EXCLUSIVE. Adding your own mechanisms on top just
means another thing for you to test independently, which seems like
adding complexity.
I do recognize that none of the above necessarily applies to specific
environments, where you need to do your own thing anyway. I'm just
commenting that in general, SQLite is already simple to use.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
