In a very large program, made of a lot of 'subsystems', some methods might have to do some read and update work, sometimes being called from contexts where there already is an OUTER transaction open, and sometimes being called with no OUTER transactions open.
If I could be satisfied with a DEFERRED transaction, programming those sub-parts so that they use SAVEPOINT ... RELEASE would be OK (right wether or not there already is an OUTER transaction (BEGIN ... COMMIT) setup by the caller). But when the job made by such sub-parts need a BEGIN IMMEDIATE before doing its reads and updates, SAVEPOINT can't elegantly be used for that. So the caller has to pass on to the sub-parts wether it already has a transaction or not, such that the subparts know wether to do their own BEGIN ... COMMIT or not. There is nothing wrong in having to do that and that works fine of course. It just pollutes some interfaces and being able to rely on an extended SAVEPOINT would keep it simpler. You use the sqlite3_autocommit() to determine if you are in "magical" mode or inside a transaction. If you are in "magical" mode then you need to issue an appropriate BEGIN to begin a transaction (with options such as IMMEDIATE if you want). Though, how do you know when you are done (as in COMMIT). I would also point out that if you do not know whether you are inside a transaction or not, then you have other problems. How do you know when you are "done" if you don't know when to BEGIN? So I suppose you could use normal method that you would have to do with every other SQL Database enginer on the planet: outer_transaction = False if sqlite3_autocommit() == 0: outer_transaction = True if outer_transaction: SAVEPOINT xxxxxx; else: BEGIN IMMEDIATE ... do stuff ... if outer_transaction: RELEASE xxxxxx; else: COMMIT; -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
