> Le 30 juil. 2019 à 23:19, Keith Medcalf <kmedc...@dessus.com> a écrit : > > I would think that adding a new lock type may be confusing and would prefer > something like adding a SHARED or READ keyword after IMMEDIATE > > BEGIN IMMEDIATE [SHARED|[UPDATE]] [TRANSACTION] > > where the default is UPDATE if not specified. This will have the least > effect on backwards compatibility but still makes it obvious that you are > requesting an immediate lock, just a SHARED/READ lock rather than an intent > to update lock.
Keith, in the context of WAL mode, I fail to see why it would be beneficial to obtain any lock immediately, when the transaction being setup using BEGIN (DEFERRED) is intended to only read. Until it actually has started to read (which it will always be able to do), why would it matter that a writer did write and commit between the "reader" BEGIN and its first read? What do I miss here? — Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit besten Grüßen, Olivier Mascia https://www.integral.be _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
