- From: Marc Fawzi <marc.fawzi@gmail.com>
- Date: Mon, 23 Jun 2014 13:03:20 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Joshua Bell <jsbell@google.com>, ben turner <bent.mozilla@gmail.com>, Webapps WG <public-webapps@w3.org>
Joshua, you're on, and I'll be happy to make suggestions once I've thought them through... At least to some extent :) Jonas, << There is a small performance difference between them though when applied to indexes. Indexes could have multiple entries with the same key (but different primaryKey), in which case count() would have to find all such entries, whereas exists() would only need to find the first. >> Isn't it also possible to open cursor on an index with IDBKeyRange.only(key) ? Wouldn't that confirm/deny existence and you may abandon the cursor/transaction after it. Having said that, and speaking naively here, a synchronous .exists() or .contains() would be useful as "existence" checks shouldn't have to be exclusively asynchronous as that complicates how we'd write: "if this exists and that other thing doesn't exists then do xyz" However, a good Promises implementation (see Dexie.js as a potential inspiration/candidate for such) may allow us to work with such asynchronous existence checks in a way that keeps the code complexity manageable. Take all this with a grain of salt. I'm learning how to use IDB as I go and these are my mental notes during this process, so not always making total sense. Marc Sent from my iPhone > On Jun 23, 2014, at 12:21 PM, Jonas Sicking <jonas@sicking.cc> wrote: > > There is a small performance difference between them though when > applied to indexes. Indexes could have multiple entries with the same > key (but different primaryKey), in which case count() would have to > find all such entries, whereas exists() would only need to find the > first.
Received on Monday, 23 June 2014 20:03:50 UTC