W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2013

Why not be multiEntry and array keyPath togather?

From: Kyaw Tun <kyawtun@yathit.com>
Date: Thu, 25 Apr 2013 22:09:45 +0800
Message-ID: <CAFPCW96wZKt0MmtTEPVPrNOGTX0JO19=6tViGcRd81=0=Ekhiw@mail.gmail.com>
To: public-webapps@w3.org
 createIndex<http://www.w3.org/TR/IndexedDB/#widl-IDBObjectStore-createIndex-IDBIndex-DOMString-name-any-keyPath-IDBIndexParameters-optionalParameters>API
specification state that "If keyPath is and Array and the multiEntry
property in the optionalParameters is true, then a DOMException of type
NotSupportedError must be thrown".

I believe NotSupportedError is unnecessary. multiEntry is no different than
non-multiEntry index value, except the reference value is repeated. This
specification limit generalizes usage of composite index for key joining
algorithm.

Google appengine datastore also have have multiEntry
(ListProperty<https://developers.google.com/appengine/docs/python/datastore/typesandpropertyclasses#ListProperty>).
It has no special different in indexing, other than limiting number of
entries<https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/1fTct9AO1MY>and
warning for possibility of explosive index.

Composite index with multiEntry is very useful, like modelling graph data
and many-to-many relationship. Currently query on such model are limited to
single index.

It is also very unlikely that web developer will use excessive indexing. I
propose NotSupportedError left out of specification.

Best regards,
Kyaw
Received on Thursday, 25 April 2013 14:10:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:18:49 UTC