However, row-level locking is something else; I see this as being too complex to implement in the 3.x series, if SQLite ever implements it; so no vote for this. In fact, the existing support to lock the whole database that 3.x supports now, which allows for multiple concurrent readers, is quite powerful on its own considering the simplicity. That said, if row-level locking is supported later, it should probably be a compile-time option, since it would slow things down for people that don't use it from the overhead.
-- Darren Duncan
At 10:42 AM -0400 5/7/05, basil thomas wrote:
We have not currently upgraded to version 3.xx even though there has been many enhancements
that have made it an even better SQL library. There are 2 features that I would suggest be added in the near future:
1) row locking - this seems to be a touchy subject as any mention of explicit row locking will take SQLite from a standalone/embedded library to a full-blown client/server type architecture. I do not know all the internals of SQLite locking except that locking the database is severly limiting concurrency if running multiple threads. I have read the concurrency document and would really like to know how hard it would be to add row/page locking to SQLite??
2) stored procedures - I know the response will probably be a flat at "NO because SQLite is not a client/server database and if you want that feature use xxx instead". I just would like to save my queries inside the database without having to recompile them again. Very simple as we seem to have triggers already and they look just like the stored procedures that I would like to create. No flow control and access to passed in variables only.
