RE: [indexeddb] Count property on IDBCursor

On Thursday, June 23, 2011 7:42 PM, Jonas Sicking wrote:
> On Thu, Jun 23, 2011 at 5:34 PM, Israel Hilerio <>
> wrote:
> > Is there a reason why we don't have a count or number of records
> > property on IDBCursor?  Pablo told me that we used to have one.  What
> happened to it?
> > It will be great to bring it back.
> The problem is that counting the number of records in a given range can be a
> very expensive operation. There are various database implementations out
> there that lets you get an approximate count for a given key range, but that
> isn't good enough if since we want interoperability across implementations.
> Since getting an exact count is a pretty expensive operation generally, we
> don't want to force implementations to always calculate the count every time
> a cursor is created. Hence getting the count would have to be an
> asynchronous operation, which would look pretty awkward as an API on the
> cursor object I think.
> What could possibly make more sense is to add
> IDBRequest count(in IDBKeyRange range)
> on IDBObjectStore and IDBIndex. My main concern with that is that while
> that seems like a pretty cheap operation, in the order of get(), it might be as
> slow as creating a cursor and iterating each entry while increasing a counter
> (minus the overhead of crossing between C++ and JS for every callback). But
> maybe that's ok.
> / Jonas

I understand where you're coming from regarding performance.  I like your idea of adding a count method to the IDBObjectStore and IDBIndex.  This will deal with the scenarios we're thinking about.  Do you want to add this to the spec or want us to do that?



Received on Monday, 27 June 2011 17:43:28 UTC