Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?

On 4 April 2011 20:58, Jonas Sicking <jonas@sicking.cc> wrote:

> On Monday, April 4, 2011, Joran Greef <joran@ronomon.com> wrote:
> > On 04 Apr 2011, at 7:28 PM, Mikeal Rogers wrote:
> >
> >> the biggest bottleneck here in the current implementation would be the
> transaction overhead on a database this size, which is because of
> performance problems in sqlite which is underlying the implementation.
> sqlite can't fix this, it's currently the problem. the object serialization
> is not a huge performance issue, performance issues in databases are almost
> always do to IO or transaction locks.
> >
> >
> > You do not have me convinced. I have tried these things (and was once an
> avid CouchDB user), and one of the first things I learnt was that object
> deserialization/serialization incurs a massive performance penalty. Just
> measure the time it takes to JSON.parse/JSON.stringify 50,000 objects on an
> iPad and then implement an indexing scheme that avoids this overhead and
> compare the performance times.
> >
> >> you should most definitely be able build sqlite on top of IDB, there
> would be a performance penalty of course, which we can address, but you
> should be able to do it. if you can't then we need to extend the
> specification.
> >
> > Trust me on this Mikeal, you cannot build SQLite on top of IDB, the
> primitives are simply not there. I have been asking for the specification to
> be extended (namely with regards to schema-less index operation, set
> operations on indices, and opaque objects) and one or two of the
> contributors have expressed interest but Mozilla do not appear to be
> enthralled.
>
> I've asked time and again for concrete proposals. I really don't think
> we are going to get any further without that. My impression is that
> people disagree on what the API should look like. Some want something
> higher level API like SQL, others want lower level with an even
> smaller feature set than what we have now.
>
> Personally I think we can solve the requested use cases using additions in
> v2.
>
> Until we have actual proposals on the table I don't see making any
> major rewrites of the API.
>
> / Jonas
>
>
This main is tagged [WebSQL] and hence is an appropriate place to discuss a
successor to WebSQL.  The answer IMHO is not to try and make IndexedDB an
unfocused hybrid trying to do too many things.

Personally I would like to see IndexedDB as a focused low level API, sort of
a web BerkeleyDB.  I would also like to see a relational API as a successor
to WebSQL. Maybe this could be something like RelationalDB - its certainly
the only proposal I have seen with sound mathematical underpinnings in
relational-algebra, and a working implementation (admittedly on top of
WebSQL, but the API will be the same no matter what technology is used to
provide the back-end).

I would like to see RelationalDB as a successor to WebSQL. It has a very
clean API with a minimal but relationally-complete set of function calls.
There should be no need to add extra parameters or methods beyond those
outlined in the current implementation. Any future requirements
(internationalisation etc) can be supported by adding  additional qualifiers
to the set passed to attribute declarations, or perhaps some additional
primitive data-types.

I really would encourage people to look at RelationalDB before implementing
any relational API. It represents a well researched API, based on research
done by myself and others, which in turn was based on research by the guys
that did HaskellDB. It has a declarative syntax for in-code schema
definition, and treats relations as real objects that can be operated on
with relational-operators. Here is a real working (tested in chrome) example
of a query:

tx.query(
    kids.join(candySales, kids.attributes.id.eq(candySales.attributes.kid))
    .group(kids.attributes.id)
    .project({name: kids.attributes.name, count:
kids.attributes.id.count()})
).onsuccess = function(results) {
    var display = document.getElementById('purchaseList');
    results.forEach(function(item) {
        display.textContent += '\t' + item.name + ' bought ' + item.count +
' pieces\n';
    });
};

So far I have had no negative comments about the API, nor has anyone been
able to suggest any improvements.


Cheers,
Keean.