Re: [IndexedDB] Multientry and duplicate elements
On Fri, Mar 2, 2012 at 8:49 PM, Israel Hilerio wrote: > There seems to be some cases where it might be useful to be able to get a > count of all the duplicates contained in a multiEntry index. Do you guys > see this as an important scenario? Not exactly sure what you mean here. Do you mean duplicates in the form of the same value existing for multiple entries, i.e. (assuming there's an index on the 'a' property) store.add({ a: [10, 20], ... }, 1); store.add({ a: [10, 30], ... }, 2); here there's a duplicate of the value 10. I.e. here you can count the duplicates by doing: index.count(10).onsuccess = ...; This will give 2 as result. Or do you mean duplicates in the form of the same value existing for the same entry, i.e.: store.add({ a: [30, 30] }, 3); Currently in firefox this won't produce a duplicate entry in the index. I.e. index.count(30).onsuccess = ...; will give 1 as result. It seems to me that it would introduce a lot of complexities if we were to insert two rows here to allow tracking duplicates. First of all there would be no way to tell the two entries apart using the API that we have now which seems like it could be problematic for pages. Second, cursor's iteration is currently defined in terms of going to the next entry which has a higher key than the one the cursor is currently located at. So if two entries have the exact same key, the cursor would still skip over the second one of them. In other words, we would have to redefine cursor iteration. This is all certainly doable, but it seems non-trivial. It would also complicate the datamodel in the implementation since the index would no longer be simply a btree of indexKey + primaryKey. An additional key would need to be added in order to tell duplicate entries apart. / Jonas
Re: [IndexedDB] Multientry and duplicate elements
On Fri, Mar 2, 2012 at 8:49 PM, Israel Hilerio wrote: > We would like some clarification on this scenario. When you say that FF > will result on 1 index entry for each index that implies that the duplicates > are automatically removed. That implies that the multiEntry flag doesn’t > take unique into consideration. Is this correct? Not quite. In Firefox multiEntry indexes still honor the 'unique' constraint. However whenever a multiEntry index adds an Array of entries to an index, it first removes any duplicate values from the Array. Only after that do we start inserting entries into the index. But if such an insertion does cause a 'unique' constraint violation then we still abort with a ConstraintError. Let me show some examples: store = db.createObjectStore("store"); index = store.createIndex("index", "a", { multiEntry: true } ); store.add({ x: 10 }, 1); // Operation succeeds, store contains one entry store.add({ a: 10 }, 2); // Operation succeeds, store contains two entries // index contains one entry: 10 -> 2 store.add({ a: [10, 20, 20] }, 3); // Operation succeeds, store contains three entries // index contains three entries: 10->2, 10->3, 20->3 store.add({ a: [30, 30, 30] }, 4); // Operation succeeds, store contains four entries // index contains four entries: 10->2, 10->3, 20->3, 30->4 store.put({ a: [20, 20] }, 3); // Operation succeeds, store contains four entries // index contains three entries: 10->2, 20->3, 30->4 Similar things happen for unique entries (assume that the transaction has a errorhandler which calls preventDefault() on all error events so that the transaction doesn't get aborted by the failed inserts) store = db.createObjectStore("store"); index = store.createIndex("index", "a", { multiEntry: true, unique: true } ); store.add({ x: 10 }, 1); // Operation succeeds, store contains one entry store.add({ a: 10 }, 2); // Operation succeeds, store contains two entries // index contains one entry: 10 -> 2 store.add({ a: [10] }, 3); // Operation fails due to the 10 key already existing in the index store.add({ a: [20, 20, 30] }, 4); // Operation succeeds, store contains three entries // index contains three entries: 10->2, 20->4, 30->4 store.add({ a: [20, 40, 40] }, 5); // Operation fails due to the 20 key already existing in the index store.add({ a: [40, 40] }, 6); // Operation succeeds, store contains four entries // index contains four entries: 10->2, 20->4, 30->4, 40->6 store.put({ a: [10] }, 4); // Operation fails due to the 10 key already existing in the index // store still contains four entries // index still contains four entries: 10->2, 20->4, 30->4, 40->6 store.put({ a: [10, 50] }, 2); // Operation succeeds, store contains five entries // index contains six entries: 10->2, 20->4, 30->4, 40->6, 50->2 To put it in spec terms: One way to fix this would be to add the following to "Object Store Storage Operation" step 7.4: "Also remove any duplicate elements from /index key/ such that only one instance of the duplicate value exists in /index key/". Maybe also add a note which says: "For example, the following value of /index key/ [10, 20, null, 30, 20] is converted to [10, 20, 30]" For what it's worth, we haven't implemented this in Firefox by preprocessing the array to remove duplicate entries. Instead we for non-unique indexes keep a btree key'ed on indexKey + primaryKey. When inserting into this btree we simply ignore any collisions since they must be due to multiple identical entries in a multiEntry array. For unique indexies we keep a btree key'ed on indexKey. If we hit a collision when doing an insertion, and we're inserting into a multiEntry index, we do a lookup to see what primaryKey the indexKey maps to. If it maps to the primaryKey we're currently inserting for, we know that it was due to a duplicate entry in the array and we just move on with no error. If it maps to another primaryKey we roll back the operation and fire a ConstraintError. Let me know if there's still any scenarios that are unclear. / Jonas
[Bug 16224] New: Change .readyState to use string values rather than numeric constants
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16224 Summary: Change .readyState to use string values rather than numeric constants Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: jo...@sicking.cc QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Numeric constants sucks when used in javascript. Code like if (es.readyState == EventSource.CONNECTING) { ... } is both harder to read and harder to type compared to if (es.readyState == "connecting") { ... } All the uppercase letters are a pain to type and and stick out like a sore thumb. Additionally there's a very real risk that people will write code like if (ws.readyState == 0) { ... } since '0' is so much easier to write than 'EventSource.CONNECTING'. It's even likely that comparing to a string is faster than comparing to EventSource.CONNECTING since the latter involves a property lookup. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 16223] New: Change .readyState to use string values rather than numeric constants
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16223 Summary: Change .readyState to use string values rather than numeric constants Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: jo...@sicking.cc QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Numeric constants sucks when used in javascript. Code like if (ws.readyState == WebSocket.CONNECTING) { ... } is both harder to read and harder to type compared to if (ws.readyState == "connecting") { ... } All the uppercase letters are a pain to type and and stick out like a sore thumb. Additionally there's a very real risk that people will write code like if (ws.readyState == 0) { ... } since '0' is so much easier to write than 'WebSocket.CONNECTING'. It's even likely that comparing to a string is faster than comparing to WebSocket.CONNECTING since the latter involves a property lookup. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [IndexedDB] Multientry with invalid keys
This should now be fixed in editor drafts. On Sat, Mar 3, 2012 at 2:58 AM, Jonas Sicking wrote: > Oh, I missed Joshua's last email. So it seems everyone is in agreement. I'll > make the edits and then close the bug. > > / Jonas > > > On Saturday, March 3, 2012, Jonas Sicking wrote: >> >> Crap, we need to better about filing bugs :-) >> >> Yes, my understanding is that there was agreement to update the spec such >> that if evaluating and index's keyPath does not yield a valid key that does >> not affect weather the value is inserted in the objectStore. >> >> In other words, indexes do not add constraints other than when explicitly >> called out using the 'unique' feature. >> >> My logic was that it would be consistent with this behaviour to ignore any >> invalid keys in a multiEntry index rather than to throw the whole thing out. >> >> If people are on with this ill edit this into the spec over the weekend. >> >> / Jonas >> >> On Saturday, March 3, 2012, Israel Hilerio wrote: >>> >>> I’ve created a bug to track this issue: >>> >>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16211 >>> >>> >>> >>> Israel >>> >>> >>> >>> On Friday, March 02, 2012 4:39 PM, Odin Hørthe Omdal wrote: >>> >>> From: "Israel Hilerio" >>> >>> > Unfortunately, we didn’t update the spec to reflect this agreement. >>> >>> > You or I could open a bug to ensure the spec is updated to capture >>> >>> > this change. >>> >>> >>> >>> Yes, better get it into the spec :-) >>> >>> >>> >>> About the behavior itself, FWIW, I think it's a reasonable one. >>> >>> >>> >>> -- >>> >>> Odin, Opera
Re: [fileapi] timing of readyState changes vs. events
On Fri, 02 Mar 2012 23:31:38 +0100, Eric U wrote: On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren wrote: Uhm. What you need to do is queue a task that changes the state and fires the event. You cannot just fire an event from asynchronous operations. Pardon my ignorance, but why not? Is it because you have to define which task queue gets the operation? Yeah, otherwise it would be undefined when the operation occurs relative to other asynchronous tasks, such as timeouts, events, and fetching. So would that mean that e.g. the current spec for readAsDataURL would have to queue steps 6 and 8-10? Yeah. Actually, I think you want to queue a single task when the read is completed and then do 7, 8, 6, 9, 10 within that task (in that order, the current order seems wrong). -- Anne van Kesteren http://annevankesteren.nl/