Deleting All Records In Indexeddb Object Store For A Specific Index Value

For an object store with an array key of [a,b] where a is also an index, is there a more efficient way to delete all records for a specific value of a than opening a cursor on the

Solution 1:

It appears that what I wasn't understanding is that the key parameter for an index is not the key of the actual record but the key of the index, here the topic value. For read operations and cursors, that works fine; but there is not a delete method on an index, such as a deleteAll equivalent to getAll.

You are correct, key is the index key. And there is no single command to say "delete every record matching a certain key or key range in an index". Here is some discussion about this - my interpretation is that there isn't a great argument against that functionality existing, but it's a rare enough use case that it's just sat there as an unimplemented feature request.

However if the primary key is an compound key and the first entry in the compound key is the field you want to filter on, you can use a KeyRange and pass it to IDBObjectStore.delete like you suggested:

In this particular case, a is a positive integer excluding zero and b is a positive integer including zero. Would a key range from [n,0] to [n+1,0] be guaranteed to return all keys for equivalent to index a=n regardless of the value of b? For example, IDBKeyRange.bound( [2,0], [3,0], false, true) would return all keys for index a=2?

Yes, that would work.

You can play around with it an see for yourself too:

varrange = IDBKeyRange.bound( [2,0], [3,0], false, true);
console.log(range.includes([2, -1])); // false
console.log(range.includes([2, 0])); // true
console.log(range.includes([2, 100])); // true
console.log(range.includes([2, Infinity])); // true
console.log(range.includes([3, 0])); // false

Just for fun... you could also define your key range like this:

varrange = IDBKeyRange.bound( [2,0], [2,""], false, true);

since numbers sort before strings. There's a bunch of other ways you could write the same thing. It all comes down to how cross-type comparisons are done in the IndexedDB spec. As soon as you have arrays or multiple types, things get interesting.