On 26/04/2013 22:18, Andrew Sutherland wrote:
Specifically, it does not look like IndexedDB's model; it still does a lot of fsync's in order to maintain the requisite SQL ACID semantics.
Right, we can't expect miracles just by moving from SQLite3 to SQLite4, though it still uses an enhanced WAL mode that has a better impact on fsyncs, and also improves a lot on database fragmentation, that is very often one of the worst offenders in SQLite3.
Unless we exposed that low level key-value store, SQLite 4 would look exactly the same to consumers.
It indeed allows us to directly use the low level store, we should indeed have a more classical Storage-like API, wrapping the SQLite API (possibly with single-threaded connections and far less mutexes), but also make a very simple key/value API using the low level store API.
Our IndexedDB implementation, for one, could probably see a good performance boost from a switch to SQLite4.
I agree, SQLite 4 won't be a solution, since, as Taras said, the solution must be built with the use-case in mind and many solutions can be better than a database engine. Though, it can surely be part of the solution. The idea would be to make a very clear documentation stating what's the best storage to use for specific needs. Guiding consumers to the right choice is much better than trying to follow a nonexisting general solution.
I think would be very good to start investigating a new Storage based on SQlite 4 along this year, even if that project has not yet released a stable branch, we would be ready for that time and probably have measurements to make informed decisions.
PS: while I love indexedDB and I think a very good work has been done there, I'm a bit scared we are evaluating a wrapper around a wrapper (Storage) around a relational ACID database engine as a general solution.
-m _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
