Re: [sqlite] sqlite3_update_hook and transactions
Make the hook queue a GUI update transaction and execute those transactions following the COMMIT. Discard the list of GUI update transactions on a ROLLBACK. Jef Driesen wrote: I was planning to use the sqlite3_update_hook function to notify my GUI about changes. The idea was that every part of the GUI can update itself when a database change is detected. But during testing, I encountered some problems with this approach together with transactions. When I group some SQL statements inside a transaction (for performance or because they have to succeed or fail all together), the callback function is executed for every statement: BEGIN statement 1 -> callback function called statement 2 -> callback function called COMMIT But if the COMMIT is replaced with a ROLLBACK (for instance when an error is detected), the callback functions are still called and the GUI is updated with data that is not actually written to the database. Any ideas on how to prevent this from happening? - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite3_update_hook and transactions
Jef Driesen <[EMAIL PROTECTED]> wrote: > > I think that approach should work. But the function sqlite3_commit_hook > is marked experimental in the documentation. What does that means? Is it > safe to rely on it? > "Experimental" means that we reserve the right to change it in future releases of SQLite. Most of the API is guaranteed to continue to be supported in exactly its current form. So, for example, when we wanted to enhance the behavior of sqlite3_prepare() we had to do so by adding sqlite3_prepare_v2(), not by changing the existing sqlite3_prepare(). And when the reason for existance of the sqlite3_global_recover() API went away, we still have to have an API with that name that is a no-op. With sqlite3_commit_hook(), we don't want to be bound by that contract. If in the future somebody comes up with a great idea for enhancing the behavior of sqlite3_commit_hook(), we want to be able to make the change without adding sqlite3_commit_hook_v2(). Or if somebody finds a fatal flaw in the whole sqlite3_commit_hook() concept, we'd like to be able to remove the API all together. Sqlite3_commit_hook() will not change without good reason. But if a good reason does come up, because it is experimental, it might change. Does that mean you can't rely on it? I suppose the answer to that question depends on what you mean by "rely on". Most libraries treat *every* API as if it were experimental. This is especially true the open-source world. SQLite tries to provide some guarantee of compatibility from one release to the next in order to preserve backwards compatibility. But we also try to give ourselves some wiggle room by explicitly declaring certain functions as experimental and therefore subject to change. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite3_update_hook and transactions
On Mon, 2007-03-12 at 10:51 +0100, Jef Driesen wrote: > I was planning to use the sqlite3_update_hook function to notify my GUI > about changes. The idea was that every part of the GUI can update itself > when a database change is detected. But during testing, I encountered > some problems with this approach together with transactions. > > When I group some SQL statements inside a transaction (for performance > or because they have to succeed or fail all together), the callback > function is executed for every statement: > > BEGIN > statement 1 -> callback function called > statement 2 -> callback function called > COMMIT > > But if the COMMIT is replaced with a ROLLBACK (for instance when an > error is detected), the callback functions are still called and the GUI > is updated with data that is not actually written to the database. > > Any ideas on how to prevent this from happening? Accumulate updates in a custom data structure (list or something) each time the update_hook() callback is invoked. Also register callbacks with sqlite3_commit_hook() and sqlite3_rollback_hook(). When the commit_hook() callback is invoked, update the GUI. When either the commit or rollback hooks are invoked, reset the data structure to empty. Dan. - To unsubscribe, send email to [EMAIL PROTECTED] -
