Re: [IndexedDB] Key paths need to be specified better
On Fri, Jun 8, 2012 at 10:42 AM, Odin Hørthe Omdal wrote: > Kyle Huey skreiv Fri, 08 Jun 2012 19:22:54 +0200 > > > In particular the spec states that key paths are DOMStrings, and then >> goes on to state how Array key paths are handled. Whatever changes are >> made need to preserve the note about key paths not nesting just after 4.7.1. >> > > Definately seconded. We've had some misunderstandings because of this. You > can give an array of keyPaths both consumers, but IDBObjectStoreParameters > is totally lying straight to our face by saying "DOMString?". > IDBObjectStore.createIndex IDL is "any keyPath", which is correct. It may > even be clearer to write (DOMString? keyPath or DOMString[] keyPath) or do > an overload. You'd have to ask someone who knows WebIDL better :-) > I believe the correct type is "(DOMString or DOMString[])?". That is, a nullable union of DOMString or an array of DOMStrings. - Kyle
Re: [IndexedDB] Key paths need to be specified better
On Fri, Jun 8, 2012 at 10:42 AM, Odin Hørthe Omdal wrote: > Kyle Huey skreiv Fri, 08 Jun 2012 19:22:54 +0200 > > >> In particular the spec states that key paths are DOMStrings, and then goes >> on to state how Array key paths are handled. Whatever changes are made need >> to preserve the note about key paths not nesting just after 4.7.1. > > > Definately seconded. We've had some misunderstandings because of this. You > can give an array of keyPaths both consumers, but IDBObjectStoreParameters > is totally lying straight to our face by saying "DOMString?". > IDBObjectStore.createIndex IDL is "any keyPath", which is correct. It may > even be clearer to write (DOMString? keyPath or DOMString[] keyPath) or do > an overload. You'd have to ask someone who knows WebIDL better :-) > > You are supposed to give keyPaths as arrays, they can be very useful. It > will build a new array of the values it found from each of the keyPaths > that's used as a key. They won't disappear, they exist in all IDB > implementations - the unclarity stems from the spec. Agree. We should define that a keyPath is a string which follows a particular syntax, or an array of strings which all follow that same syntax. There should be no place in the spec where a string-keypath is valid but a array-keypath is not. Could someone please file a bug on this. / Jonas
Re: [IndexedDB] Key paths need to be specified better
Kyle Huey skreiv Fri, 08 Jun 2012 19:22:54 +0200 In particular the spec states that key paths are DOMStrings, and then goes on to state how Array key paths are handled. Whatever changes are made need to preserve the note about key paths not nesting just after 4.7.1. Definately seconded. We've had some misunderstandings because of this. You can give an array of keyPaths both consumers, but IDBObjectStoreParameters is totally lying straight to our face by saying "DOMString?". IDBObjectStore.createIndex IDL is "any keyPath", which is correct. It may even be clearer to write (DOMString? keyPath or DOMString[] keyPath) or do an overload. You'd have to ask someone who knows WebIDL better :-) You are supposed to give keyPaths as arrays, they can be very useful. It will build a new array of the values it found from each of the keyPaths that's used as a key. They won't disappear, they exist in all IDB implementations - the unclarity stems from the spec. -- Odin (odinho / Velmont) - Opera Software
[IndexedDB] Key paths need to be specified better
In particular the spec states that key paths are DOMStrings, and then goes on to state how Array key paths are handled. Whatever changes are made need to preserve the note about key paths not nesting just after 4.7.1. - Kyle
