boolean should be a valid key

[yathit]

Being only two possible values, boolean data type is not a good key by itself. But query do involve boolean value. For examples, we want to count numbers of records in which a field value is false or true. In this case, full table scan is required. A workaround like shadow field defeat the original argument (that boolean is not a good key).

Boolean value is also useful in compound index. It is not possible now.

Key comparison can be defined that all number values are greater then all boolean values. Should modification could work without breaking existing database.

Indexing boolean value is such a common gotcha in indexeddb usage.

Since boolean is a primitive data type, all other nontrivial data types are valid key, why not boolean? For consistency sake, boolean should be a valid key.

[inexorabletash]

Thanks for linking to the StackOverflow issue!

This seems reasonable, although we'd need to define sorting precedence. If boolean sorts before number then -Infinity ceases to be the first possible key. Also, I know Gecko's implementation of key serialization is carefully crafted to allow "memcmp" sorting, so I'm not sure how easy it is for them to add a new type.

[sicking]

As long as bools are "grouped together" it should be fine. I.e. as long as we don't do something crazy like sort true before number and false after.

[dfahlander]

👍

[nolanlawson]

CouchDB's collation order is null -> booleans -> numbers -> strings -> arrays -> objects, FWIW.

[jakearchibald]

Hah, I just got tripped up by this when trying to create an index on ['active', 'startDate'], where active is a boolean.

[brettz9]

Incidentally, what about undefined or null for that matter too (as for index keypaths set to test for the presence of null or (explicit or even sparse) undefined)?

And slightly off topic but interconnected, what exactly is the reason for the IdentifierName restrictions (such as no whitespace) comprising key paths (and the lack of a mode to escape full stops to allow for targeting any path)? Is there some crucial low-level reason for this, or was the decision made just to avoid foot-guns with inadvertently untrimmed paths?

It seems to me a pity that each point in a cloneable (or at least JSON) object can't, as it appears to me, be targeted for querying (and updating for that matter).

[alastairpatrick]

I would like to see Boolean become a valid key type in IndexedDB. I have some concerns about where Boolean might appear relative to other key types in the key ordering. I am writing this against the IndexedDB spec dated 8/1/15 but am aware of the IndexedDB 2 draft.

The current IndexedDB key ordering is Number < Date < String < Array. The Booleans could be inserted in one of five places in the existing order. My notes on each option follow.

1. Boolean < Number < Date < String < Array

Currently, the least value that can be used as a key is -Infinity. If Booleans came first instead of Numbers, the least key value would become Boolean false.

More importantly, today a key with array value [1, 2, 3] is immediately followed by [1, 2, 3, -Infinity], meaning there is no key after [1, 2, 3] that comes before [1, 2, 3, -Infinity]. If Booleans were to be the first key type, [1, 2, 3] would instead be immediately followed by [1, 2, 3, false], potentially a breaking change.

Code based on the current specification that uses IDBKeyRange.bound([1, 2, 3], [1, 2, 3, -Infinity], false, true) to find records equal to [1, 2, 3] would come to spuriously yield records equal to and prefixed with [1, 2, 3, false] and [1, 2, 3, true].

The reason such code might not use the simpler IDBKeyRange.only([1, 2, 3]) for this purpose is because of composite key paths. Consider a composite key path ["a", "b"]. Attempting to find all records with "a" equal to [1, 2, 3] with IDBKeyRange.only([1, 2, 3]) would yield no results because, with the value of "b" appended, all records with "a" equal to [1, 2, 3] come after IDBKeyRange.only([1, 2, 3]) in the key ordering. To account for this, the solution is to use a closed upper bound set to the value immediately following [1, 2, 3], which can be calculated using the rules set forth in the specification.

2. Number < Boolean < Date < String < Array:

If Boolean were inserted between Number and Date, the key value immediately following Infinity would change from being Date(-8640000000000000), the earliest representable date, to being Boolean false. Additionally, the key immediately preceding Date(-8640000000000000) would change from being Infinity to being Boolean true.

Attempts by existing code to use ranges like IDBKeyRange.bound(Infinity, new Date(-8640000000000000), false, true) to find records with "a" equal to Infinity in composite keys paths ["a", "b"] would come to yield spurious results.

3. Number < Date < Boolean < String < Array:

If Boolean were inserted between Date and String, the key value immediately following Date(8640000000000000) would change from being the empty String("") to being Boolean false.

Attempts by existing code to use ranges like IDBKeyRange.bound(new Date(8640000000000000), "", false, true) to find records with "a" equal to Date(8640000000000000) in composite keys paths ["a", "b"] would come to yield spurious results.

4. Number < Date < String < Boolean < Array:

If the Booleans were inserted between String and Array, I think things look good. While there are still ranges that will yield different lists of records, there are ways to work with this change to the ordering, at least with respect to its interaction with composite key paths.

Importantly, inserting Booleans between Strings and Arrays does not result in any case where the key that immediately follows some other key is different from the way it was before. The reason is because there would be no string followed immediately by false in the key ordering; rather, the value immediately following any string in the ordering is always that string juxtaposed with the null character '\0'.

One caveat is Internet Explorer / Edge. Neither of these (henceforth IE) implement array keys. A cross-browser workaround is to use String keys with a special array encoding instead of Array keys in IE. If Booleans were inserted between Strings and Arrays, Booleans would follow Arrays (aka Strings) in IE while Booleans would precede Arrays in other browsers.

5. Number < Date < String < Array < Boolean:

As noted above, the value immediately following any array in the ordering is that array appended with the value -Infinity, e.g. [1, 2, 3] is immediately followed by [1, 2, 3, -Infinity]. Similar to Booleans following Strings, this means introducing Boolean after Array would not change the key that immediately followed any other key, and seems workable.

I am wary that where before the ordering terminated with the "infinite" Array keys, the ordering would come to terminate with the finite Boolean keys. This means the greatest key value would come to be a tangible value, specifically Boolean true. This invites code that actually uses Boolean true as a bound that is assumed to be greater than all others, which could impede adding further new key types after the Booleans in the future.

Summary

If Booleans are to become valid keys, as a general rule, I think they should follow one of the “infinite” key types, either String or Array, so that in no case does the key that immediately follows any other key change. This is so that existing key ranges work as anticipated in association with composite key paths. To ensure that the greatest key value does not have a finite representation, I think I prefer to put the Booleans between the Strings and the Arrays. However, if a future IE is expected to support Boolean keys without also supporting Array keys, there might be an argument for having Boolean follow Array, so that existing hacks to support Arrays in IE continue to work consistently in a world with Boolean keys. Of course, I would much prefer IE to support Array keys.

I suggest addressing other potentially indexable key types, such as null, at the same time, to make sure everything plays nice. Changes like this are perilous!

Going forward, this kind of issue, where the ordering of one type of key relative to others is relied upon outside of the IndexedDB implementation, could be avoided if the APIs for querying records took separate ranges for each element of a composite key path rather than a single key range for the whole composite key path.

Here is existence proof of code that would be impacted by the introduction of Boolean key values as described in the examples above. Its vulnerability to the specification of key ordering is clear in the nextUp function, which is at the top of the linked file at the time of writing. I am sure other applications and libraries would be affected too.

[nolanlawson]

It looks like we can close this issue? Binary keys are now in IDB 2.0, and there is also a definition of the sorting algorithm here:

As a result of the above rules, negative infinity is the lowest possible value for a key. Number keys are less than date keys. Date keys are less than string keys. String keys are less than binary keys. Binary keys are less than array keys. There is no highest possible key value. This is because an array of any candidate highest key followed by another key is even higher.

[inexorabletash]

This issue is about supporting the boolean types true and false. The binary type is shorthand for ArrayBuffer keys.

[nolanlawson]

My bad. 😅 Yes, boolean keys would be useful.

[inexorabletash]

Yeah, would be good to add. No rush to implement on our side.

Good first spec PR for someone once we are done with 2.0 ?