Yeh I think this is the way to go currently. I just wanted to be sure I understood it correctly and that it doesn’t exist already.
Is there a standard place where people can request features to be added to SQLite? The Fossil repo perhaps? On Wed, 31 Jul 2019 at 12:53, Richard Damon <rich...@damon-family.org> wrote: > As has been pointed out, your function that is called can do the BEGIN > and then a SELECT that hits the database to force the obtaining of the > read lock. The fact that the BEGIN didn't get the lock is then not seen > by the users of your API. > > IF at some point a new BEGIN SHARED IMMEDIATE operation becomes > available, you can change you function's internals, and the caller > doesn't know the difference except that the call got perhaps a bit faster. > > On 7/31/19 6:36 AM, test user wrote: > > Quote: What importance does it have for you that it already holds an > > "end-mark? > > Quote: Why would it matter that a writer did write and commit between the > > "reader" BEGIN and its first read? > > > > Im writing a library and would like to have an API where the "read > > transaction" has a clear beginning in time. > > > > BEGIN IMMEDIATE forces a "write transaction", but there is no counterpart > > for a "read transaction". > > > > As an example, the client of this library could: > > > > - A. Obtain a "read transaction", *without running any SELECTs*. > > - B. Complete 20 write transactions in another process. > > - C. Begin reading from the read transaction (A) at the point before the > > transactions had occurred. > > > > > > At the moment, a "read transaction" is only started on the first SELECT. > > > > If a client tries to start a "read transaction" with BEGIN, and that > > returns SQLITE_OK, its not clear that this has not actually begun any > > transaction until the first SELECT query. > > > > This would enable an API like: > > > > const r = await db.startReadTx(); > > const w = await db.startWriteTx(); > > > > // At this point in the runtime it clear when the transactions have > begun, > > and how they will impact other concurrent read/write transactions. > > > > > > > > On Tue, Jul 30, 2019 at 11:40 PM Olivier Mascia <o...@integral.be> wrote: > > > >>> Le 31 juil. 2019 à 00:22, Keith Medcalf <kmedc...@dessus.com> a écrit > : > >>> > >>> I can see where a BEGIN IMMEDIATE SHARED would be useful in non-WAL > mode > >> though. I will grant that there may be cases where it might be useful > in > >> WAL mode, even though I cannot think of any. > >> > >> Fully agree. > >> > >> — > >> Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit > besten > >> Grüßen, > >> Olivier Mascia > >> > >> _______________________________________________ > >> sqlite-users mailing list > >> sqlite-users@mailinglists.sqlite.org > >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > >> > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > -- > Richard Damon > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
