Hello, If I would have one wish, it would not be the row level locking but the merge syntax, so usefulf to update, insert or update in 1 command (no insert or replace is not an equivalent), and in general it would be good to implement the sql 2003.
Just a wish. Best regards, Sylvain Le lundi 11 novembre 2013, Raheel Gupta a écrit : > @simon > > I guess a Row level locking could be difficult but a Page Level locking > could be not that difficult. > > ATM "db level locking" : > If DB locked throw busy error > In not locked lock db, let the writer do its thing > > For Page level locking (I think you could allow something like) : > Let writer write / modify pages IF not locked > ONLY If writer comes across a locked page wait for it to be released > > In this way, multiple threads could do writes. Again I am not an expert but > from my little understanding this might not remove the leaness. You are the > expert. > > And even I agree that Sqlite must be "lite" > > > > On Sun, Nov 10, 2013 at 8:39 PM, Simon Slavin > <slav...@bigfraud.org<javascript:;>> > wrote: > > > > > On 10 Nov 2013, at 12:05pm, Raheel Gupta <raheel...@gmail.com<javascript:;>> > wrote: > > > > >>> I can't think of any other single feature that would remove the > "lite" > > > > > > I am not a database expert. If you say so, it must be the case. > > > But if there is a way to implement concurrent writers in SQLite > > maintaining > > > the "lite" in SQLite, I would be the most happiest person here :) > > > > The main reason you seem to prefer SQLite to other databases is that it's > > faster. Adding row-level locking to SQLite would slow it down a lot. > As a > > very simplified explanation, for one SELECT instead of > > > > try to lock the database > > check to see that the lock on the database is yours > > FOR EACH ROW: > > figure out where the row's data is > > read the data > > unlock the database > > > > you have to do > > > > FOR EACH ROW: > > figure out where the row's data is > > try to lock the row > > check to see that the lock on the row is yours > > read the data > > release the row > > > > If your SELECT returns 10 rows you end up doing 50 operations instead of > > 23. Which would mean that SQLite was half the speed, and no longer had > any > > advantages for you, so you would use something else. > > > > Locking is the single hardest thing to get right when writing a DBMS. > > SQLite gets a lot of its tininess and speed by implementing the simplest > > fastest method of locking possible. > > > > Simon. > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org <javascript:;> > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org <javascript:;> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
