Re: IndexedDB, what were the issues? How do we stop it from happening again?

Sorry for dropping previous content in this thread, but I just
subscribed to this list and the only way I found to reply to older
messages is by using archives and "respond to this message" link.

It seems that people criticize IndexedDB quite a lot and I don't quite
agree with most of the criticism. I have been playing with IDB for
couple of months now I actually quite like it. It has its shortcomings,
but I think NoSQL database is very good choice as browser based
database and there are multiple reasons why I favour this approach over
embedding SQL DBMS.

First of all, IDB is very easy to use. Promise based request API should
be easy for anyone familiar with Javascript programming and libraries
like jQuery. Also the specification is fairly simple to implement by
different browser vendors.

IDB is also very suitable for mobile devices. My experiences with SQL
is that it is fairly complicated and developers often end up very
inefficient queries. This is especially problematic in mobile devices
where it can have serious impact on power consumption. On the other
hand, lack of query language can lead cause developers to iterate
through all items to find those they need, but I think this is lesser
evil than problems I have seen with SQL. CouchDB has concept of views
that help on this matter, but with IDB those needs to be created
separately when indices are not enough or you need to go over object
store boundaries.

When comparing to CouchDB, something I'm missing is ability to
subscribe events when there are changes in the database. I was somewhat
disappointed realizing that there is no similar mechanism in IDB. What
I would like to see is Object Store events for new, modified and
deleted objects. This would allow writing generic library for data
replication or creation of dictionary for global or database level
search. As an addition these events would provide easy way of keeping
multiple windows in-sync. There are ways go around lack of these
events, but not very elegant ones.

Other shortcoming is the lack of UUID or other globally/universally
unique IDs as object keys. When thinking about NoSQL world, having these
feels just obvious and I'm amazed that this is not the default ID format
for IDB or at least required as an alternative by the specification.
This is a must to have feature for creating proper synchronization
libraries. You can use something like uuid-v4.js and generate your ids
by hand, but as far as I know uuid-v4.js trusts Math.random() that has
its own issues and same applies to all UUID Javascript implementations.
So in the end it would be nice to have browser provided UUIDs that are
working properly and key generator that provides UUID based ids.

So, I think IDB is fairly nice API and I don't really understand all
the criticism when use of SQL based solution would be much more
complicated to implement and use, and current IDB API is easy to learn
by anyone who has experience of Javascript combined with jQuery or
similar libraries. Another problem with SQL based solution would be the
question of which version of the standard to match or would this be yet
another SQL standard version.

As a user of IDB most important items on my wish list are:
1) new, modify and delete events for Object Store. I suppose right time
for emitting these events is after transaction is complete.
2) UUID based key generator and would be great if this UUID generator
can be used for other purposes too.

As a hobby, I'm in the middle of modifying Mozilla's implementation to
provide this
so that I have Firefox that I can use to do my experiments.

-- 
Miko Nieminen
miko.nieminen@iki.fi   
miko.nieminen@gmail.com

Received on Monday, 11 February 2013 14:06:59 UTC