Consider adding a simple(ish) query engine

[jurca]

I would like to propose opening a discussion about including a query engine API to make the use of IndexedDB a little easier.

I suppose the right point where to start would be adding a query engine that can be used on a single object store at a time, does not support aggregate operations on sets of records, and internally uses a single cursor opened on an index or the object store itself to execute the query. The goal would be to create an API every vendor could agree upon, and then build on top of it based on vendor & developer feedback.

The API might look something like this:

// connect, start a transaction, retrieve object store

const queryRequest = objectStore.query({
  filter: {
    alternatives: [
      {
        properties: [
          {
            propertyPath: ['foo', 'bar'],
            valueRange: IDBKeyRange.lower(3),
            expandMultiEntry: true
          },
        ],
      },
      {
        properties: [
          {
            propertyPath: ['foo', 'xyz'],
            valueRange: IDBKeyRange.upper(5),
            expandMultiEntry: true
          },
        ],
      },
    ],
  },
  skipFirst: 16,
  recordLimit: 8,
  examinedRecordsLimit: 128
})
queryRequest.onsuccess = () => {
  const cursor = queryRequest.result
  if (!cursor) {
    return // done
  }

  // do something with cursor.value

  cursor.continue()
}

// Alternative use:

objectStore.getAll({
  onlyUnique: [
    {
      propertyPath: ['abc'],
    },
  ],
  orderBy: [
    {
      propertyPath: ['p1', 'p2', 'p3'],
      direction: 'ASCENDING',
      expandMultiEntry: false,
    },
    {
      propertyPath: ['x'],
      direction: 'DESCENDING',
      expandMultiEntry: false,
    },
  ],
}).onsuccess = ({target: {result}}) => {
  console.log("Fetched records", result)
}

A more detailed proposal of what such a query engine might look like and work under the hood is here: https://github.com/jurca/indexed-db-query-engine.

The linked proposal is just a collection of ideas and a discussion starter, nothing more.

This would fix #19 and serve as a basis for #298.

Whether you think it would be better to start with something even simpler, or more complex, or the right way to solve this is SQLite in WASM, or go in a different direction, I would love your feedback. I personally think that a wattered-down version of the above would make IndexedDB API more convenient to use.