All true, unless you want a relational data model. (and note a relational data _model_ is not dependant on the backend, but some engines have many man-years of work spent on them that I would not want to try and replicate).
I dont see what you mean by better, SQLite seems pretty good to me. I don't see Google's Android team, or the iPhone dropping it any time soon. I suspect that WebKit will be keeping WebSQL support. Cheers, Keean. On 26 October 2010 20:54, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Tue, Oct 26, 2010 at 12:04 PM, Keean Schupke <ke...@fry-it.com> wrote: > > Take Firefox for example, it implements IndexedDB using SQLite > apparently. > > So implementing a relational API if we have to talk to IndexedDB that > means > > we have to convert from the relational data model to an object model and > > then back to a relational model for SQLite. So what I would like to do is > > punch through that excess layer in the middle and have the relational API > > talk directly to SQLite in the browser implementation. How could you > argue > > that having an unnecessary middle layer is a good thing? > > The SQLite back-end used by Firefox's implementation of IndexedDB (and > Chrome's, for the moment) is unnecessary; at least in Chrome's case, > we used a SQLite backend only because it was expedient and the code > was there. We'll be changing it to a better backend in the future, > and I suspect that Firefox will do the same in time. > > The middle layer isn't unnecessary, *it's the whole point*. The > back-end shouldn't ever be exposed directly - you don't want your code > to break if we drop the SQLite backend and switch to a direct > b-tree-based backend. > > ~TJ >
