[w3c/IndexedDB] Custom index keys (#204)

For scenarios like full-text search it's often necessary today to augment a record with additional data purely to populate an index. For example:
```js
  store.createIndex('fulltext', 'terms');

  record.terms = FullText.GenerateTerms(record.body); 
  store.put(record);
```
If this data isn't necessary for record otherwise it duplicates storage and reduces performance (e.g. serialization/deserialization).

One proposal is to allow expressions when indexing, e.g. replacing the key path with a function (see https://github.com/w3c/IndexedDB/issues/33). This has lots of complexity lurking - how is the expression persisted? Is it idempotent? A simpler variation would be to allow specifying the index terms when storing the record:
```js
  store.createIndex('fulltext', 'terms');

  const terms = FullText.GenerateTerms(record.body); 
  store.put(record, undefined, {fulltext: terms});
```
`put()` (and `add()` and `update()`) would gain a third optional argument, a __record<DOMString, any>__. The key would be the index name, the value is the key to use for the named index. If specified, the index's key path is not used for that value. If an index's name is not present in the record, the index's key path is used as normal.

If a value initially stored with custom keys is and replaced (via `put()`) or updated (via `update()`) then the caller probably wants to specify custom index keys again, otherwise the key path will be used.

Issues:
* Should the record key be the _name_ of the index, or the _key path_ of the index? If the key path, things get interesting if multiple indexes use the same key path (e.g. within array key paths).
* If an index is created after a store is already populated, the key path is used for population. How would a developer go about populating such an index?
* Indexes that always expect custom keys (e.g. the full text example above); its key path would never be used, which is a bit of a wart.

Maybe we should simply recommend maintaining a manual index as a secondary store instead.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/204