Re: IDBObjectStore/IDBIndex.exists(key)

On Sat, Jun 21, 2014 at 7:02 PM, Marc Fawzi <marc.fawzi@gmail.com> wrote:

> I think the same thought pattern can be applied elsewhere in the API
> design for v2.
>
> Consider the scenario of trying to find whether a given index exists or
> not (upon upgradeneeded). For now, we have to write noisy code like
> [].slice.call(objectStore.indexNames()).indexOf("someIndex")  Why couldn't
> indexNames be an array?
>

Technically, objectStoreNames() and indexNames() are specified to return a
DOMStringList, which is an array-like with a contains() method, so you can
write:

objectStore.indexNames().contains("someIndex")

... however, DOMStringList fell out of vogue pretty much as soon as it was
created. ISTR that Firefox just returns a JS Array here. But there's been
talk about adding contains() to Array.prototype:

http://esdiscuss.org/topic/array-prototype-contains

... which seems likely for ES7 in some form or another. Ideally we'd add
Array.prototype.contains() and then indexNames().contains() works
cross-browser (and we can delete DOMStringList from Chrome!).


>  and dare we ask for this to either return the index or null:
> objectStore.index("someIndex")  ? I understand the argument for throwing an
> error here but I think a silent null is more practical.
>

I don't think we can change that for compat reasons.

Aside: The API design definitely assumes "you know what you're doing", e.g.
introspecting a database schema is abnormal, since you (as the site author)
should of course know exactly what the schema is, except during upgrades
when you have the monotonically increasing version number to reason
against. Of course, the minute you build an abstraction layer on top of the
IDB API it's no longer abnormal and the API feels clunky.


> So yes, anything that makes the API easier to consume would be terrific.
>

More thoughts welcome!

I gave specific counters to your two concrete suggestions above, but please
don't let that stop you. These rough edges in the API should be smoothed
out!


> I had a very hard time until I saw the light. There's some solid thought
> behind the existing API, but it's also not designed for web development in
> terms of how it implements a good idea, not wether or not the idea is good.
> Sorry for the mini rant.
>

No need to apologize, it's appreciated. "v2" thinking needs to include
making the API more powerful, more usable, and more approachable.


> It took me a little too long to get this app done which is my first time
> using IndexedDB (with a half broken debugger in Chrome):
> https://github.com/idibidiart/AllSeeingEye
>
>
>
>
>
>
> On Sat, Jun 21, 2014 at 5:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> Hi all,
>>
>> I found an old email with notes about features that we might want to put
>> in v2.
>>
>> Almost all of them was recently brought up in the recent threads about
>> IDBv2. However there was one thing on the list that I haven't seen brought
>> up.
>>
>> It might be a nice perf improvement to add support for a
>> IDBObjectStore/IDBIndex.exists(key) function.
>>
>> This would require less IO and less object creation than simply using
>> .get(). It is probably particularly useful when doing a filtering join
>> operation between two indexes/object stores. But it is probably useful
>> other times too.
>>
>> Is this something that others think would be useful?
>>
>> / Jonas
>>
>
>