RE: [indexeddb] Count property on IDBCursor
Added count() to IDBIndex, IDBIndexSync, IDBObjectStore, and IDBObjectStoreSync. Updated the editor's draft. Let me know if any changes are required. Thanks, E > -Original Message- > From: public-webapps-requ...@w3.org [mailto:public-webapps- > requ...@w3.org] On Behalf Of Jonas Sicking > Sent: Tuesday, June 28, 2011 12:50 PM > To: Israel Hilerio > Cc: public-webapps@w3.org > Subject: Re: [indexeddb] Count property on IDBCursor > > On Mon, Jun 27, 2011 at 10:42 AM, Israel Hilerio > wrote: > > 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? > > Would be great if you could add this. Please do make the function able to > take both a IDBKeyRange or a value, like .get() and .delete() does. > > / Jonas >
Re: [indexeddb] Count property on IDBCursor
On Mon, Jun 27, 2011 at 10:42 AM, Israel Hilerio wrote: > 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? Would be great if you could add this. Please do make the function able to take both a IDBKeyRange or a value, like .get() and .delete() does. / Jonas
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? Thanks, Israel
Re: [indexeddb] Count property on IDBCursor
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
[indexeddb] Count property on IDBCursor
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. Israel
