This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We should probably specify objectStoreNames order. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBDatabase-objectStoreNames http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBDatabaseSync-objectStoreNames I suggest changing: > On getting, this attribute must return a list of names of the object stores > currently in the connected database. To: > On getting, this attribute must return a list of names of the object stores > currently in the connected database sorted in ascending order. Should also specify what we mean by sorted in ascending order here. Probably the same as is already said for comparing DOMStrings in keys. E.g. step 5 of http://es5.github.com/#x11.8.5
I think alphabetic or creation order would be the two simplest solutions.
Agreed that it should be specified. I lean slightly towards lexical order rather than creation order since creation order might require some implementations to store additional data just for that purpose. This should apply to the IDBObjectStore.indexNames attribute as well.
I concur with Joshua Bell.
I would prefer if we were to return them using creation order. Returning them in alphabetic order works well (for US) until you start having to deal with collations, then things get complex very quickly.
(In reply to comment #4) > I would prefer if we were to return them using creation order. Returning them > in alphabetic order works well (for US) until you start having to deal with > collations, then things get complex very quickly. FWIW, I would assume that if we're sorting them follow the same order that JavaScript strings sort, by comparing 16-bit units, not actually alphabetical-in-a-real-language or according to any Unicode collation. e.g. [ "", "\x00", "0", "1", "A", "B", "a", "b", "\xC0, "\xFF", "\uD7FF", "\uD800\uDC00", "\uE000", "\uFFFF" ]
I'm not sure that using JavaScript strings sorting provides a meaningful solution. Developers will still have to sort their objectStore names if they want to guarantee that they are correctly sorted ("A", "a", "B", "b", etc.). Israel
IMHO, the intent of this issue is to ensure the stores are reported in deterministic order, not necessarily an order that's useful.
Reading objectStoreNames and indexNames may not be what you do as your bread and butter, but it's nice having them interoperable between implementations. We never know what crazy code someone will write ;-) I really prefer the stupid lexical sort over creation order, because of the implementation issue Joshua highlighted. Lexical is just an easy sort right before returning the names. Creation order on the other hand means we've got to store extra information about every object store and index.
Sounds reasonable, we agree! While we already return our object store and index names using creation date ordering, we're okay with changing this internal behavior to return them (object store names and index names) in lexical sort order. The good news is that we don't see this change impacting any of our internal and external partner implementations. We're definetely looking forward to having IDB be one of the new interoperable storage solutions on HTML5.
Sounds good to me.
Fixed for both objectStoreNames and indexNames. I used the same reference for sorting order as we use for strings when sorting keys.
Fixed