4 ms·

IndexedDB has much to learn from SQLite

12 points by jorangreef 16y ago

jorangreef 16y ago
The web would be healthier if it had two competing APIs in SQLite and IndexedDB. Mozilla must come to the party and provide access to an embedding of SQLite. It would be hubris to suggest they can design something better and to remove the alternative before they have done so.
- arethuza 16y ago
  I think I can see both sides of this argument - on one side there is the fact that SQLite is available, is a great bit of software and is already built into a number of browsers, on the the other hand it does seem slightly odd to have specification that references an implementation ("do whatever version X.Y.Z of SQLite did). If they supported both then everyone would probably use SQLite and the standard Web stack becomes directly dependent on a particular implementation of something - which I don't think has ever been the case before. Personally, I'd go with SQLite, preferably with a synchronous interface as well. But I can understand the reservations of those who don't.
  - rfugger 16y ago
    Mozilla's plan is to implement IndexedDB on top of SQLite, and then encourage developers to re-implement SQL in Javascript on top of that. https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... Sounds to me like a ludicrous hoop to make people jump through just to avoid an ad-hoc standard based on an implementation.
    - jorangreef 16y ago
      Yes, except Mozilla have to yet to show that it can be done. They are yet to understand that IndexedDB does simply not provide enough low-level primitives to implement SQL let alone have even a chance of coming within 10 orders of magnitude of the performance of SQLite. There's a design flaw in IndexedDB, namely IndexedDB does not regard objects as opaque. This is the first thing you'd need (followed by variable length records) if you wanted to implement SQLite on IndexedDB. Ships will sail around the earth but the flat earth society will flourish.
aw3c2 16y ago
flamebait link to a mailinglist rant
- jorangreef 16y ago
  It's a pivotal thread, it's not a rant. It's likely that Mozilla may provide access to an embedding of SQLite, if enough developers pay attention to these discussions now. If you have already used IndexedDB to store more than 500,000 objects on an iPad and you were satisfied with it, and it didn't crash, then I would rest my case.
  - StavrosK 16y ago
    To reinforce your point, I stored about 70,000,000 rows in one table in a SQLite database and a few million rows in other tables on the same database, and it was fast, reliable and delightful to work with. Anyone who goes against SQLite will have a lot of work ahead of them.
    - hendler 16y ago
      I've also worked with SQLite, and one project was the using the C API. It's also why I really liked Google Gears. Here's the Google Tech Talk on SQLite from 2006 http://www.youtube.com/watch?v=giAMt8Tj-84&feature=channel_page http://www.youtube.com/watch?v=giAMt8Tj-84&feature=chann...
saurik 16y ago
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0053.html http://lists.w3.org/Archives/Public/public-webapps/2011AprJu... ^ that post is infinitely more interesting (the argument for RelationalDB) http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0055.html http://lists.w3.org/Archives/Public/public-webapps/2011AprJu... ^ click "stored" after "text/html attachment" (an argument against RelationalDB)
lvh 16y ago
"... and with better test coverage at that." Oh wow. I thought he was serious until he was suggesting there exists software in the world with a more comprehensive test suite than SQLite.

12 points by jorangreef 16y ago

The web would be healthier if it had two competing APIs in SQLite and IndexedDB. Mozilla must come to the party and provide access to an embedding of SQLite. It would be hubris to suggest they can design something better and to remove the alternative before they have done so.

arethuza 16y ago
I think I can see both sides of this argument - on one side there is the fact that SQLite is available, is a great bit of software and is already built into a number of browsers, on the the other hand it does seem slightly odd to have specification that references an implementation ("do whatever version X.Y.Z of SQLite did). If they supported both then everyone would probably use SQLite and the standard Web stack becomes directly dependent on a particular implementation of something - which I don't think has ever been the case before. Personally, I'd go with SQLite, preferably with a synchronous interface as well. But I can understand the reservations of those who don't.
- rfugger 16y ago
  Mozilla's plan is to implement IndexedDB on top of SQLite, and then encourage developers to re-implement SQL in Javascript on top of that. https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... Sounds to me like a ludicrous hoop to make people jump through just to avoid an ad-hoc standard based on an implementation.
  - jorangreef 16y ago
    Yes, except Mozilla have to yet to show that it can be done. They are yet to understand that IndexedDB does simply not provide enough low-level primitives to implement SQL let alone have even a chance of coming within 10 orders of magnitude of the performance of SQLite. There's a design flaw in IndexedDB, namely IndexedDB does not regard objects as opaque. This is the first thing you'd need (followed by variable length records) if you wanted to implement SQLite on IndexedDB. Ships will sail around the earth but the flat earth society will flourish.

aw3c2 16y ago

flamebait link to a mailinglist rant

jorangreef 16y ago
It's a pivotal thread, it's not a rant. It's likely that Mozilla may provide access to an embedding of SQLite, if enough developers pay attention to these discussions now. If you have already used IndexedDB to store more than 500,000 objects on an iPad and you were satisfied with it, and it didn't crash, then I would rest my case.
- StavrosK 16y ago
  To reinforce your point, I stored about 70,000,000 rows in one table in a SQLite database and a few million rows in other tables on the same database, and it was fast, reliable and delightful to work with. Anyone who goes against SQLite will have a lot of work ahead of them.
  - hendler 16y ago
    I've also worked with SQLite, and one project was the using the C API. It's also why I really liked Google Gears. Here's the Google Tech Talk on SQLite from 2006 http://www.youtube.com/watch?v=giAMt8Tj-84&feature=channel_page http://www.youtube.com/watch?v=giAMt8Tj-84&feature=chann...

saurik 16y ago

http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0053.html http://lists.w3.org/Archives/Public/public-webapps/2011AprJu... ^ that post is infinitely more interesting (the argument for RelationalDB) http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0055.html http://lists.w3.org/Archives/Public/public-webapps/2011AprJu... ^ click "stored" after "text/html attachment" (an argument against RelationalDB)

lvh 16y ago

"... and with better test coverage at that." Oh wow. I thought he was serious until he was suggesting there exists software in the world with a more comprehensive test suite than SQLite.