I understand your semantic point but this helps no one. Coming from other databases and SQL in general the term "transaction" has a very specific meaning. So if the documentation talks about read transactions in some places and shared locks in other places I think these are different things.
Let's say I use a MySQL client, do not request a read transaction but I see somewhere that the MySQL server will need an internal shared lock to satisfy the SELECT query, what do I care? If what you say is true then I think it would greatly help the documentation to replace all occurrences of "read transaction" with "shared lock" and thereby introduce ubiquitous language and reduce confusion. mit freundlichen Grüßen, Kira Backes On Mon, 12 Aug 2019 at 13:30, Olivier Mascia <[email protected]> wrote: > > Could you please understand that this is only a matter of language? > > There is no hard thing as a read transaction. But it is commonly intuitive to > name a transaction as « read » as long as it did not started with write > intent and self-restraint itself from doing writes. > > -- > Best regards, Meilleures salutations, Met vriendelijke groeten, > Olivier Mascia (from mobile device) > > Le 12 août 2019 à 13:19, Kira Backes <[email protected]> a écrit : > > >> There is no such thing as a "READ transaction". > > > > Could you please open the following google query: > > > > https://www.google.com/search?q=%22read+transaction%22+site%3Asqlite.org > > > > There are 300 mentions of "read transaction" in the documentation and > > commits > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
