IndexedDB and complex keypaths for index RRS feed

  • Question

  • Does msIndexedDB in the current DP support complex key paths like in this scenario:

      id: "track1"
      name: "We will rock you"
      tags: [ 
        { id: "tag1", name: "queen" }, 
        { id: "tag3", name: "pop" } 
      id: "tag1"
      name: "queen"
      tracks: ["track1"]
      id: "tag2"
      name: "michael jackson"
      id: "tag3"
      name: "pop"

    Normally, to fetch all tracks tagged with "pop" I would have an index on the "tracks" store like this "tags[].name". But this does not seem to work. Is there something wrong with my keypath or does msIndexedDB not yet support this kind of index?

    Wednesday, February 22, 2012 10:10 AM

All replies

  • I do not see this as a provision here:


    (unless I just don't see it).

    Jeff Sanders (MSFT)

    Thursday, February 23, 2012 8:49 PM
  • See here


    It clearly states "... or multiple Javascript identifiers separated by periods".

    I found a unit test for Firefox from last year, and I think Chrome handles such keypaths correctly too. Unless I have something misunderstood. But without such complex keypaths an IndexedDb is pretty much only usable for the most simple kind of object stores and relations, imho.

    And if that is the case, we will have to go the sqlite3 route and try to compile the source for WinJS as winmd Component.

    • Proposed as answer by Israel Hilerio Friday, February 24, 2012 6:59 PM
    • Unproposed as answer by Israel Hilerio Friday, February 24, 2012 6:59 PM
    Thursday, February 23, 2012 9:40 PM
  • Unfortunately, the IndexedDB spec doesn't define a keyPath syntax for using attributes contained within an array object as indexes or keys.  The use of the period to separate javascript attributes is used on objects [1].  While Arrays can be used for keys, there is no mechanism for specifying attributes contained by an object inside an array.  One reason is that there is no valid keypath syntax like the one you proposed, "tags[].name", supported by the spec.  We should probably look into this for the next version of the IDB spec, v2.

    The good news is that, you can easily achieve what you want today by creating a second object store to store all of the tag arrays:

    ObjectStore1 (Tracks): key:id
    {id: "track1"
      name: "We will rock you"

    ObjectStore2 (Tags): key: auto-gen

    {id:auto-gen, trackId: "track1", tagId: "tag1", tag: "queen"}

    {id:auto-gen, trackId: "track1", tagId: "tag3", tag: "pop"}

    Then, I would create an index (unique flag false) on tag and trackId.  This will allow me to search against all the tags directly, using an IDBKeyRange, to retreive all of the related tracks from my search using the cursor value and looking for the trackId property.  You could do a similar thing by using the trackId index and searching for specific trackIds.

    [1] http://www.w3.org/TR/IndexedDB/#key-path-construct

    Program Manager, Windows Workflow Foundation

    Friday, February 24, 2012 7:48 PM
  • Thanks Israel for your answer. So what you are suggesting is basically a traditional join table.

    To get detailed informations for a tag I would need to do another object store fetch though.

    So I think I will go with SQLite3 from the beginning then. Just cannot get the current source compiled with VS11 on x64. Let's hope somebody else has a precompiled md binary for that in the beta store tomorrow :)

    Out of curiosity: Have you and your team done any performance tests on IE 10 IndexedDB implementation regarding several 100k of entries in stores? And is the data somehow compressed on disk or can we expect the IndexedDB storages to grow fast when doing migrations from one version of the DB to another?

    Tuesday, February 28, 2012 8:25 AM
  • Isreal, this seems to be fixed now according to this tests you submitted:


    and the fact that you mentioned "properties in blobs" here:


    Can you please clarify?

    • Edited by phil_ke Tuesday, March 27, 2012 1:43 PM
    Tuesday, March 27, 2012 1:41 PM
  • keyPath is the second most beautiful part of IndexedDB API. the first will be implicit transaction.

    The three hidden power of keyPath are:

    1. doted keyPath: it is used to extracted nested value from an object. Implementation is very simple and IE should support. 
    2. Value of keyPath is array: this lead to listed index and many-to-may relationship.
    3. keyPath is array: this lead to compound index. 

    It is in the spec explained in algorithmic fashion. 

    For performance check out my demo: http://dev.yathit.com/demo/ydn-db/nosql/nosql-demo.html 100k is not a problem. The best part is you can query them under a range of 100ms. The query has filters and sorted.

    But note, the demo use above keyPath feature. So check out with either chrome or firefox. 

    Friday, November 30, 2012 2:30 AM