IndexedDB multientry RRS feed

  • Question

  • IndexedDB has a feature for indices called multientry.  It allows you to place an index on an array field, so that you can create a cursor on the index and search by the array values.

    According to MSDN, createIndex accepts the optionalParameters parameter which includes multiEntry.  Another article shows it as being multientry (all lower case).

    I've tried both, and neither work as far as I can tell. In the debugger the index object contains properties for "unique" (another optional parameter) but not multientry or multiEntry.

    Could someone at Microsoft please clarify how to use multiEntry and if it is supported. A google and bing search returns only these two pages.



    Monday, July 23, 2012 10:35 PM


All replies

  • According to the RFC, you would do something like this:

    var dbOptionalParams = { multientry: true };

    and pass that in.  Did you try that?

    Jeff Sanders (MSFT)

    Tuesday, July 24, 2012 2:08 PM
  • Yes I have.  I've tried both multientry: true and multiEntry: true.  According to the spec the value returned from the createIndex call is an IDBIndex object, which should contain a multiEntry property.  When I look in the debugger, no such property exists, which makes me think the IE team hasn't implemented multiEntry yet.  Can you ask that team about it?  I feel like they will be the only ones that know for sure.


    Tuesday, July 24, 2012 5:16 PM
  • Matthew,

    For what I know, is the attribute multiEntry not implemented, but the functionality is. This is the same for the object store. There you have the option autoIncrement, but the attribute to get the value afterwards is not implemented.

    I hope Microsoft will implement these attributes in the future. But for now, you can use them, but not access them.



    Kristof Degrave - Software Engineer RealDolmen www.kristofdegrave.be

    Tuesday, July 24, 2012 6:20 PM
  • This is fantastic news!  The attribute is not really useful in most situations (I suppose if you used some 3rd party library that didn't know about your database it might be useful for them).

    So this just means that I am doing something incorrectly that is causing the cursor not to find any results.  I'll try and throw together a test application and post it here for others to learn from (multiEntry is the worst documented part of IndexedDB currently).  Off the top of my head this is what I think the problem may be:

    Let's say the index is an on a field called states.  So an object might be: { company: 'foo', states: [ 'kentucky', 'new york' ] }.  And so using IDBKeyRange.only('kentucky') should find this object, correct?  However what if when the object was first put into the objectStore it didn't contain the property state, but that it was only updated to include it later?  Might the data not be reindexed (I would think that it should but this is just my first idea)?

    Wednesday, July 25, 2012 12:19 PM
  • I confirmed this has not been implemented yet

    Jeff Sanders (MSFT)

    Wednesday, July 25, 2012 5:34 PM
  • Thanks a lot for doing the research Jeff!  I think it might be possible to polyfill this, so I'm going to give that a shot and if I succeed I'll post the results here.
    Thursday, July 26, 2012 12:06 AM
  • Hi Jeff,

    what do you exactly mean by not implemented. Do you mean the functionality or the attribute?



    Kristof Degrave - Software Engineer RealDolmen www.kristofdegrave.be

    Friday, July 27, 2012 5:20 AM
  • Kristof,

    They said they did not implement either yet.  Are your findings different?


    Jeff Sanders (MSFT)

    Friday, July 27, 2012 1:37 PM
  • I started writing a test application but stopped when Jeff said it wasn't implemented.

    Good news is that I'm 90% sure this can be shimmed. An index is, conceptually if not implemented this way, just another objectStore with the values as the key and the key as the value. So you can shim in support by hijacking calls to IDBObjectStore.prototype.put and IDBObjectStore.prototype.add and, if the objectStore has a multiEntry index (which you can find out by hijacking IDBOjectStore.prototype.createIndex), then store the multiEntry values in another objectStore.

    Then on the retrieval side you have to hijack calls to IDBIndex.prototype.openCursor, IDBIndex.prototype.openKeyCursor, IDBIndex.prototype.get, IDBIndex.prototype.getKey, and IDBIndex.prototype.count. So far I've done createIndex, add, put, and openCursor. Written at least, completely untested at this point.

     I think I'll have something useful within a couple of weeks (well, unless we find out that the functionality is already implemented, that would be better). You can follow along or contribute here.

    Friday, July 27, 2012 7:43 PM
  • Hi ipsanders,

    I retested it, and came to the same conclusion. It's not possible :(


    Kristof Degrave - Software Engineer RealDolmen www.kristofdegrave.be

    Saturday, July 28, 2012 11:57 AM
  • Brand new polyfill that is tested against Web Platform tests: https://github.com/dfahlander/idb-iegap

    The polyfill makes IE support both multiEntry and compound indexes and also compound primary keys according to the IDB spec.

    Monday, December 1, 2014 12:49 AM