Re: [w3c/IndexedDB] Issues with key and keyPath usage (#308)

Re: `keyPath`:
* This would ideally be `[SameObject] (DOMString or sequence<DOMString>)` but `sequence<>`s are not permitted for attributes IIRC.
* For a given `IDBObjectStore` or `IDBIndex` instance, the attribute will always return the same value. I'm not sure why we haven't applied `[SameObject]` here. It may just predate `[SameObject]`. Anyway, that's the source of the _it returns the same object instance every time it is inspected_ prose. There's no need for a special processing model; it can lift the definition from `[SameObject]` if that attribute can't be applied.

Re: `key`

Yeah, keys are happy fun times. Perhaps ideally, we'd have a `typedef (unrestricted double or DOMString or Date or BufferSource or sequence<IDBKey>) IDBKey` but I don't think circular definitions are allowed and again sequences as attributes aren't allowed by WebIDL syntax.  I'd be more than happy to defer all of [this](https://w3c.github.io/IndexedDB/#convert-key-to-value) and [this](https://w3c.github.io/IndexedDB/#convert-value-to-key) to WebIDL but there's stuff it can't handle, and past discussions have leaned away from adding support for things only a single spec needs. Anywho...

HTML uses `any` for "an ES value" (e.g. `postMessage()`). Is the intent to change that? What's the preferred way to spec an escape hatch for arbitrary ES values that will be further processed in prose? I agree the WebIDL definition seemingly disagrees with that usage. 

Note that IDBCursor's `key` is the "easy" case. IDBRequest's `result` can be a key (per above), or a value (arbitrary deserialized ES object), or an IDBDatabase.

Suggestions (PRs, sketches of prose, napkin scribbles, etc) welcome! And as usual, apologies if I misinterpreted the feedback. Help on improving the spec is always appreciated.



-- 
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/308#issuecomment-555128422