5 ms·

If the HTML5 working draft just specified SQL92, would you jump on board? It seems like your main complain isn't relational databases, but rather the fact that

by eob 16y ago

If the HTML5 working draft just specified SQL92, would you jump on board? It seems like your main complain isn't relational databases, but rather the fact that the HTML spec, as stands, essentially specifies "whatever SQLite implemented" as its database specification.

mbrubeck 16y ago
Even if the standard said SQL92, the only practical, shippable embedded SQL database today is SQLite. I don't think browser vendors are itching to implement their own SQL databases (or if they did, that they would be any more interoperable than the various relational databases today). So realistically, if we go the SQL route, what will get is SQLite. SQL is a great language and SQLite is a great implementation. But Mozilla knows what happens in the long term when we end up with a web standard that is actually defined by a single implementation: It becomes very hard for anyone else to implement the standard interoperably, or for the standard to evolve by design rather than by accident. Programming languages are the most complicated standards of all. SQL is good, but Mozilla thinks it's better to give up the advantages of embedded SQL for a lower-level API that is more standardizable, and doesn't add another language to the web stack. (The language we have now - JavaScript - is just starting to be truly interoperable itself.) IndexedDB can and will be backed by SQLite, and the SQL language can be built back on at the JavaScript layer where it will be portable to both SQLite- and non-SQLite backends. ActiveJS already includes a SQL parser/compiler in pure JavaScript for its in-memory datastore: http://activerecordjs.org/ http://activerecordjs.org/
- blasdel 16y ago
  Everyone using SQLite instead of trying to implement their own independent interoperable stuff would be fucking awesome. There is very little software that's anywhere I would say that about, but SQLite belongs in valhalla. Reimplementing it is too much wank even for the FSF to muster. Anyone telling me that they were going to implement their own SQLite (especially a browser vendor) and ship it to millions of users to run untrusted unsanitized input would get my door smashed into the face, their nose broken and bleeding. They would deserve it.
  - mbrubeck 16y ago
    > Reimplementing it is too much wank even for the FSF to muster This must be a typo, becaus nothing is too much wank for the FSF. :)
    - blasdel 16y ago
      Well, the object proof is that there isn't even a vaporware "GNU Embedded SQL" project. Unfortunately, there is probably a Rule 34 for these things. Apologies in advance.
      - deleted 16y ago
        [deleted]
jomohke 16y ago
The other common complaint is that using plain strings for data access is inelegant, and not very javascript-y. It will face the same problem as other platforms, where developers end up writing ORM frameworks to map relational database tables (somewhat awkwardly) to objects. IndexedDB feels closer to real javascript - it does all access through javascript methods. Writing storage wrapper libraries will be cleaner against this kind of API than concatenating strings of SQL. And it does not preclude someone from writing an SQL implementation on top of it, if they desire. (Or something simpler. eg. http://thomasfrank.se/sqlike.html http://thomasfrank.se/sqlike.html)

by eob 16y ago

mbrubeck 16y ago

Even if the standard said SQL92, the only practical, shippable embedded SQL database today is SQLite. I don't think browser vendors are itching to implement their own SQL databases (or if they did, that they would be any more interoperable than the various relational databases today). So realistically, if we go the SQL route, what will get is SQLite. SQL is a great language and SQLite is a great implementation. But Mozilla knows what happens in the long term when we end up with a web standard that is actually defined by a single implementation: It becomes very hard for anyone else to implement the standard interoperably, or for the standard to evolve by design rather than by accident. Programming languages are the most complicated standards of all. SQL is good, but Mozilla thinks it's better to give up the advantages of embedded SQL for a lower-level API that is more standardizable, and doesn't add another language to the web stack. (The language we have now - JavaScript - is just starting to be truly interoperable itself.) IndexedDB can and will be backed by SQLite, and the SQL language can be built back on at the JavaScript layer where it will be portable to both SQLite- and non-SQLite backends. ActiveJS already includes a SQL parser/compiler in pure JavaScript for its in-memory datastore: http://activerecordjs.org/ http://activerecordjs.org/

blasdel 16y ago
Everyone using SQLite instead of trying to implement their own independent interoperable stuff would be fucking awesome. There is very little software that's anywhere I would say that about, but SQLite belongs in valhalla. Reimplementing it is too much wank even for the FSF to muster. Anyone telling me that they were going to implement their own SQLite (especially a browser vendor) and ship it to millions of users to run untrusted unsanitized input would get my door smashed into the face, their nose broken and bleeding. They would deserve it.
- mbrubeck 16y ago
  > Reimplementing it is too much wank even for the FSF to muster This must be a typo, becaus nothing is too much wank for the FSF. :)
  - blasdel 16y ago
    Well, the object proof is that there isn't even a vaporware "GNU Embedded SQL" project. Unfortunately, there is probably a Rule 34 for these things. Apologies in advance.
    - deleted 16y ago
      [deleted]

jomohke 16y ago

The other common complaint is that using plain strings for data access is inelegant, and not very javascript-y. It will face the same problem as other platforms, where developers end up writing ORM frameworks to map relational database tables (somewhat awkwardly) to objects. IndexedDB feels closer to real javascript - it does all access through javascript methods. Writing storage wrapper libraries will be cleaner against this kind of API than concatenating strings of SQL. And it does not preclude someone from writing an SQL implementation on top of it, if they desire. (Or something simpler. eg. http://thomasfrank.se/sqlike.html http://thomasfrank.se/sqlike.html)