So what? We should be structuring a lot of databases as layers on top of transactional key value stores. We should be able to swap out the key value store without changing the higher level query engine.
We maybe[1] should, but we are not. AFAIK there's no relational query engine for IndexedDB.
Also, there are a lot more people who can get things done with SQL than using indexed KV-stores. KV stores tending to have horrible APIs doesn't help the situation.
[1] E.g. SQLite started with a gdbm backend, but later rolled their own because of limitations caused by it.
Comments
So what? We should be structuring a lot of databases as layers on top of transactional key value stores. We should be able to swap out the key value store without changing the higher level query engine.
We maybe[1] should, but we are not. AFAIK there's no relational query engine for IndexedDB.
Also, there are a lot more people who can get things done with SQL than using indexed KV-stores. KV stores tending to have horrible APIs doesn't help the situation.
[1] E.g. SQLite started with a gdbm backend, but later rolled their own because of limitations caused by it.
There is SQL on top of IndexedDB: absurd-sql or AlaSQL.
When you build that, I will upvote the HN post to that too ;)
Don't tempt me. :-) This is what SQLite 4 was supposed to have been, BTW.