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? 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.
So yes, anything that makes the API easier to consume would be terrific.
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. 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 <[email protected]> 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
>
