16013 2012-02-17 13:05:33 +0000 objectStoreNames order should be specified (alphabetic?) 2012-03-02 16:19:48 +0000 1 1 1 Unclassified WebAppsWG Indexed Database API unspecified All All RESOLVED FIXED P2 normal --- 1 odinho dave.null israelh jonas jsbell mike public-webapps public-webapps-bugzilla oldest_to_newest 64225 0 odinho 2012-02-17 13:05:33 +0000 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 64228 1 jonas 2012-02-17 14:28:23 +0000 I think alphabetic or creation order would be the two simplest solutions. 64247 2 jsbell 2012-02-17 18:06:03 +0000 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. 64297 3 odinho 2012-02-20 09:38:58 +0000 I concur with Joshua Bell. 64509 4 israelh 2012-02-23 22:15:06 +0000 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. 64510 5 jsbell 2012-02-23 22:23:03 +0000 (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" ] 64516 6 israelh 2012-02-24 01:02:41 +0000 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 64517 7 jsbell 2012-02-24 01:06:10 +0000 IMHO, the intent of this issue is to ensure the stores are reported in deterministic order, not necessarily an order that's useful. 64536 8 odinho 2012-02-24 12:57:44 +0000 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. 64577 9 israelh 2012-02-24 23:28:27 +0000 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. 64648 10 jonas 2012-02-27 16:42:07 +0000 Sounds good to me. 64918 11 jonas 2012-03-02 16:12:02 +0000 Fixed for both objectStoreNames and indexNames. I used the same reference for sorting order as we use for strings when sorting keys. 64921 12 jonas 2012-03-02 16:19:48 +0000 Fixed