W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: IDBObjectStore/IDBIndex.exists(key)

From: Marc Fawzi <marc.fawzi@gmail.com>
Date: Mon, 23 Jun 2014 13:03:20 -0700
Message-Id: <FDFCEDB3-4DF2-4868-A682-F22C3435DEA4@gmail.com>
Cc: Joshua Bell <jsbell@google.com>, ben turner <bent.mozilla@gmail.com>, Webapps WG <public-webapps@w3.org>
To: Jonas Sicking <jonas@sicking.cc>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:25 UTC