I took that coach often and when I finally started making money I decided to splurge on the sleeper train and in time upgraded to a cabin. what luxury compared to megabus!
SQLite not being in browsers instead of indexdb saddens me today still.
I designed a system 15 years ago that released dimensional star schemas for specific reports as sqllite databases into Adobe Air (or whatever the prerelease name was) for a large retailer in the UK. We would query the data warehouse, build the sqlite db file (I can't remember the exact db sizes but they weren't too big - 15mb or so) and the computational performance we got from using sqlite as our crunching layer when building the dimensional reports with drilldown was just astounding.
Oh man, that's a shame. I remember looking into WebSQL when I was designing a little Phonegap tourist app, and ended up just using localstorage instead, like this guy, but I tucked it away as a possible technology for some use case I never quite got around to. SQLite is great and it doesn't make any sense to deprecate WebSQL in favor of some key/value "nosql db" pattern, since there are already plenty of other alternatives for storing nonrelational data.
It was deprecated because it was difficult to write a standard spec for the existing SQLite code (but a key value system is much easier to specify as there is no SQL language).
Yeah but a key value system lacks all the really good things about SQL. And locally with sqlite you don't really have to worry about latency, so you should be able to just get atomicity and consistency on the thread. This shouldn't be a lot to ask from an embedded web DB. I think as with other standards bickering, ten years from now something (Canvas API) will come out that more or less replicates the technology that was already standard ten years ago (Flash graphics), with lots of people cheering for it as if someone just invented sliced bread.
Additional issue was that to become a standard, there would have to be at least two different proof-of-concept implementations. That would mean, someone would have to write a SQLite compatible database, that is not SQLite.
>Yeah but a key value system lacks all the really good things about SQL
exactly
>And locally with sqlite you don't really have to worry about latency, so you should be able to just get atomicity and consistency on the thread
for high performance read you don't need much more.
> think as with other standards bickering, ten years from now something (Canvas API) will come out that more or less replicates the technology that was already standard ten years ago (Flash graphics), with lots of people cheering for it as if someone just invented sliced bread.
flash and actionscript revolutionized the web and a lot of what we have now web tooling wise stems to the desire to compete what flash was possible since 2003.
It's really only the write / ACID features of WebSQL that are interesting to me, though. There are lots of ways to get a high performance read on key/value pairs if you've already downloaded all the data. We don't need a new methodology for that. What's interesting is the ability for web app storage to respect foreign key constraints and transactions within a local data model, without having to rely on rolling your own middleware to resolve inconsistencies.
> Yeah but a key value system lacks all the really good things about SQL.
IndexedDB lacks SQL support natively, but there is nothing about key value systems in general that preclude the use of SQL. CockroachDB comes to mind as a key value store that depends on SQL. SQL support could be built atop IndexedDB by a willing developer. JsStore is in that vein, although the approach is a little bit different.
SQLite was not designed for arbitrary execution with control over queries and internal state. Someone demonstrated that you could redirect the pointer address for various callbacks and potentially exploit it.
The solution currently is compiling sqlite in webassembly. Though I am certainly saddened that browsers don't have some sort of web-made equivalent natively.
You would also develop and deploy against closure using simple for your dev workflow and only run advanced more infrequently. Advanced also gives deeper type schecking. I have not worked with closure compiler in years, but it is a different and incredibly powerful beast. Easily extendible with your own compile passes as well
