Re: [w3c/IndexedDB] Add descending order for getAll() and getAllKeys() (#130)

SteveBeckerMSFT left a comment (w3c/IndexedDB#130)

The [`getAllRecords()` prototype in Chromium 133](https://chromestatus.com/feature/5124331450138624) includes the direction option.  We've received feedback from developers that we should also add direction to the existing `getAllKeys()` and `getAll()`, which is what this issue is all about.  I'd like to discuss some options to try to resolve this issue:

## 1) Use `getAllRecords()` to make direction feature detectable for `getAllKeys()` and `getAll()`.

Example:

```js
const object_store = tx.objectStore("test_store");
if ('getAllRecords' in object_store) {
  // getAllRecords() introduced the IDBGetAllOptions dictionary, which can also be used with getAll() and getAllKeys().
  const get_all_options = {
    query,
    count: 5,
    direction = 'prev'
  };
  const request = object_store.getAllKeys(get_all_options);
  ...
else {
 // Fallback to a cursor with direction: 'prev' for this query.
 ...
}
```

Pros: Simple feature detection.

Cons: Browser implementors must support getAllRecords() to add direction to getAll() and getAllKeys().

## 2) Add direction to `IDBKeyRange`.

`IDBKeyRange` is the first arugment to `getAllKeys()` and `getAll()`.  We could add direction to `IDBKeyRange`'s static construction functions. For feature detection, we could add a direction attribute to the constructed `IDBKeyRange`.
For example:

```js
partial interface IDBKeyRange { 
readonly attribute IDBCursorDirection  direction = 'next';

[NewObject] static IDBKeyRange bound(any lower,
                                      any upper,
                                      optional boolean lowerOpen = false,
                                      optional boolean upperOpen = false,
                                      IDBCursorDirection  direction = 'next');
```

Feature detection looks like:

```js
if ('direction' in IDBKeyRange.prototype) {
  // Construct IDBKeyRange with a direction!
  ...
} else {
  // Fallback to a cursor.
  ...
}
```

Pros: Straightforward feature detection without adding new query functions.

Cons: Duplicates direction for `IDBCursor`.  Cursors have two direction arguments: one on `openCursor()` and one on the `IDBKeyRange` consturctor.  What happens if these arguments are not the same value?  Cursors also have two direction attributes: one on the `IDBCursor` and one on the cusor's `IDBKeyRange`.

[Also discussed above.](https://github.com/w3c/IndexedDB/issues/130#issuecomment-533412610).  

## 3) Add `isQuerySupported()` or similar function.

This function would take and return the query options dictionary.  The returned dictionary would omit any unsupported options, which enables feature detection.  For example:

```js
let query_options = {
  query,
  count: 5,
  direction = 'prev'
};
query_options = IDBDatabase.isQuerySupported(query_options);
if (query_options.direction) {
  // getAllKeys() supports direction!
  ...
}  else {
  // Fallback to a cursor.
}
```

Other W3C specs have proposed similar mechanisms:

(1) [MediaDevices::getSupportedConstraints()](https://w3c.github.io/mediacapture-main/#dom-mediadevices-getsupportedconstraints)
(2) [VideoDecoder::https://www.w3.org/TR/webcodecs/#dom-audiodecoder-isconfigsupported]

However, these examples go beyond browser feature detection by also providing platform and hardware capability detection.

If we like this option, we'd need to work out the details by trying to generalize to support both get all and cursors.

Pros: Extensible.  Can support future query additions.

Cons: Potentially large change.  Do we have any other proposed query additions where this would help?  I'm not aware of any.

[Mentioned above.](https://github.com/w3c/IndexedDB/issues/130#issuecomment-531623928)

## 4) Add `getAllKeysFromEnd()` and `getAllFromEnd()`.

Inspired by `indexOf()` and [`lastIndexOf()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/lastIndexOf).  [Discussed above.](https://github.com/w3c/IndexedDB/issues/130#issuecomment-316777178)

Pros: Feature detectable without duplicating direction state.

Cons: Does not scale if we want to add additional query options.  We should not add a new function for each new query option.

## Request for feedback

Can we reach a consensus on a path forward?  I presented these options in order of my preferences, but what do you think?  Which option should we try?

Tagging a few IDB participants for feedback: @inexorabletash, @asutherland, @evanstade, @abhishek-shanthkumar 

Thanks,
Steve

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

Message ID: <w3c/IndexedDB/issues/130/2856256605@github.com>