will major browsers support native IndexedDb sorting for BigInt? or will users need to custom-serialize it themselves in sortable form?

[kaizhu256]

also, the common-use case is likely BigInt64 (as many users might be satisfied with feature-parity with sql-databases), which may or may not simplify IndexedDb implementations by restricting native-support to that use-case.

[littledan]

Good question for IndexedDB people--cc @inexorabletash

[ajklein]

Isn't this a question about what HTML's Structured Clone should do for BigInts? @domenic @annevk

[inexorabletash]

I assume this is about use as keys (hence, sorting), not values (which cloning would cover).

Re: keys: It won't happen automagically without IndexedDB changes in all browsers, independent of ES implementation changes.

Keys in IndexedDB are defined as number, date, string, arraybuffer, or array of other keys. I haven't been following the BigInt design very closely, but the steps for converting an ES value to a key almost certainly would reject a BigInt.

Questions include:

• Is type conserved? i.e. if you store a record with a BigInt key with a value of 5, do you expect to get the key back out as the Number 5 or a BigInt equal to 5? Similarly, if you store a record with a BigInt key with a value of 5, and query with the Number 5, do you find the record?
• How are Number and BigInts keys ordered?
• Is special-casing BigInt64 desirable? It doesn't resolve the above two questions, though.

[inexorabletash]

Note that if the answers are "types are conserved" and "BigInts are greater than all Numbers and smaller than all Dates" then it's reasonably straightforward. Otherwise, we need to put on our clever glasses.

[littledan]

Is type conserved? i.e. if you store a record with a BigInt key with a value of 5, do you expect to get the key back out as the Number 5 or a BigInt equal to 5? Similarly, if you store a record with a BigInt key with a value of 5, and query with the Number 5, do you find the record?

I'd suggest that the type should be conserved, and that there shouldn't be this coercion between keys. BigInt is designed around a "no coercion" philosophy.

How are Number and BigInts keys ordered?

Operators like < compare mathematical values. However, I'd be fine with putting Number and BigInt in a particular order for IndexedDB purposes as it appears the other types are.

Is special-casing BigInt64 desirable? It doesn't resolve the above two questions, though.

I don't see why it would be, beyond supporting BigInt64Arrays as values.

[annevk]

Isn't this a question about what HTML's Structured Clone should do for BigInts?

Is there a separate issue for this? Would be nice to make that work from day one.

[annevk]

For IDB, it seems like it would be nice if Number and BigInt could occupy the same ordering slot while preserving type, if that's how they work elsewhere in JavaScript.

[littledan]

Serialization (structured clone) handling is proposed in this HTML PR. I'll follow up with a further proposal in a PR on IDB.

@annevk Number and Date can be compared in ECMAScript, but in IDB, it looks like dates are consistently "greater than" numbers. What would be the downside of following a similar pattern here with BigInt? The design of BigInt discourages its mixed use in the same domain as Number, so the impact could be less than if we were talking about another programming language.

[annevk]

If it's already inconsistent between the two I don't care much.

[littledan]

I opened a PR on IndexedDB to track the idea to permit BigInt as IndexedDB keys. Let's continue the discussion there (given that it's impossible to support within this repository).