On 13 Apr 2017, at 2:39pm, Olivier Mascia <o...@integral.be> wrote:
> Known, but thanks. :)
> The question was why SAVEPOINT, when there is no outer transaction, is
> limited to the behavior of simple BEGIN (which is BEGIN DEFERRED) and does
> not offer provision for IMMEDIATE or EXCLUSIVE mode (I'm only interested in
> IMMEDIATE for the use-case I have in mind)?
Just as with any other SQL command which accesses data, you’re not meant to
start a transaction by declaring a savepoint. SAVEPOINT should not be
acquiring locks. You should have already done a BEGIN to acquire the locks you
want.
SQLite expects you to do
BEGIN <whatever>
<commands go here>
SAVEPOINT <name>
<commands go here>
RELEASE SAVEPOINT <name>
<commands go here>
COMMIT
Just as with any other SQL command, if you forget to do your BEGIN, SQLite
wraps your command in BEGIN DEFERRED […] END , but that’s a convenience, not
something . If you prefer your lock to be EXCLUSIVE or IMMEDIATE you can
specify it in the BEGIN command.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
