Re: [w3c/IndexedDB] Track ES BigInt work (#230)

Hello, I found this issue and PR #231 after a mysterious failure upon trying to use unsigned 64-bit integers as IndexedDB keys. Our entire application is WASM built from a higher-level language, where such types are common. Originally I had read in the documentation that "numbers could be used as IndexedDB keys", but experimentally it seems like that specifically refers to a JS `Number`, namely a 64-bit **float**. Naturally a 64-bit float cannot represent all the values a 64-bit int can, so this puts us in a bit of a pickle.

My guess is that my unsigned int is represented lower down as a `BigInt` upon passing an FFI barrier, hence I'm given a "invalid key" error in my console. If I manually cast down to a 64-bit float before writing, it works.

> Right, surely you don't actually need all 64 of those bits.

Yes, you'd be correct, but the unsigned int is the result of a Standard Library hashing scheme that always yields a 64-bit value. Since that hash is already the thing guaranteeing uniqueness, the idea of shaving off bits makes me nervous. 

Would it be possible to revisit this work of supporting `BigInt`s as keys?

-- 
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/230#issuecomment-939035097