What is the reason to pay extra overhead if it can be omitted? And actually, SQLite does a great job with concurrency, from my experience. There's really smart locking model employed.
And this is really tedious to work around: 1) You cannot disable FK constraints inside a transaction 2) Would be really really silly to do so, they're here for a reason, and disabling them, even temporarily, is shooting yourself in a foot, sooner or later 3) Two queries means two primary key searches, so for a big tables it's close to 100% overhead, unnecessary 4) It's really bad to maintain two queries, INSERT and UPDATE, in your code, good place for bugs to creep in So the question is completely legitimate. What's re reason it was not implemented. And should we expect it to be born in some near future? Would be superb awesome. 20 January 2016, 12:50:23, by "Clemens Ladisch" <clemens at ladisch.de>: > chromedout64 at yahoo.com wrote: > > Will SQLite ever get an UPSERT command similar to other DBMS? > > These other DMBSes use a client/server architecture and want to achieve > high concurrency. > > SQLite has no client/server communication overhead, so there is no large > downside to using two SQL statements instead. Furthermore, SQLite has > no write concurrency, so it does not need an optimized UPSERT locking > implementation that avoids interfering with other writers. > > That said, I'd guess SQLite will get UPSERT if a paying customer wants > it. > > > Regards, > Clemens > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
