Re: Indexed database API autoIncrement
On Sunday, November 13, 2011, Shawn Wilsher wrote: > On 10/23/2011 3:04 PM, Jonas Sicking wrote: >> >> Good catch! This definitely needs to be specified in the spec. >> >> I have a weak preference for using 1. This has a smaller risk of >> triggering edge cases in the client code since it's always truthy. >> I.e. if someone tries to detect the presence of an id, they won't fail >> due to the id being 0. > > Looks like there was a [loose] consensus around one, but it's not specified as far as I can tell. Should I file a bug or will it get magically fixed with this e-mail? Please file bug. / Jonas
Re: Indexed database API autoIncrement
On 10/23/2011 3:04 PM, Jonas Sicking wrote: Good catch! This definitely needs to be specified in the spec. I have a weak preference for using 1. This has a smaller risk of triggering edge cases in the client code since it's always truthy. I.e. if someone tries to detect the presence of an id, they won't fail due to the id being 0. Looks like there was a [loose] consensus around one, but it's not specified as far as I can tell. Should I file a bug or will it get magically fixed with this e-mail? Cheers, Shawn
RE: Indexed database API autoIncrement
On October 23, 2011 3:19 PM, Charles Pritchard wrote:
> On Oct 23, 2011, at 3:04 PM, Jonas Sicking wrote:
>
> > On Sun, Oct 23, 2011 at 4:20 AM, Futomi Hatano wrote:
> >> Hello everyone,
> >>
> >> I'm not a W3C member, can I send a mail to the list?
> >
> > Absolutely! This is a public list intended for just that!
> >
> >> I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
> >> I found a different behavior between the two.
> >> I set autoIncrement to true when I created a Object Store as below.
> >>
> >> var store = db.createObjectStore(store_name, { keyPath: 'id',
> >> autoIncrement: true });
> >>
> >> Then, I added some records.
> >>
> >> IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set
> >> it
> to 1.
> >> Which is correct?
> >> I couldn't find the definition about this in the spec.
> >> The first value of autoIncrement should be defined in the spec, or
> >> the spec should allow us to set the first value of autoIncrement, I think.
> >>
> >> Sorry in advance if the discussion has already been done.
> >> Thank you for your time.
> >
> > Good catch! This definitely needs to be specified in the spec.
> >
> > I have a weak preference for using 1. This has a smaller risk of
> > triggering edge cases in the client code since it's always truthy.
> > I.e. if someone tries to detect the presence of an id, they won't fail
> > due to the id being 0.
>
> I agree -- this is also the behavior in all DBMS I've worked with. There's
> time
> for MS to update their implementation. All around win.
We are aware of the issue and we're looking to fix the problem to be
interoperable.
Thanks for the feedback.
Israel
Re: Indexed database API autoIncrement
On Oct 23, 2011, at 3:04 PM, Jonas Sicking wrote:
> On Sun, Oct 23, 2011 at 4:20 AM, Futomi Hatano wrote:
>> Hello everyone,
>>
>> I'm not a W3C member, can I send a mail to the list?
>
> Absolutely! This is a public list intended for just that!
>
>> I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
>> I found a different behavior between the two.
>> I set autoIncrement to true when I created a Object Store as below.
>>
>> var store = db.createObjectStore(store_name, { keyPath: 'id', autoIncrement:
>> true });
>>
>> Then, I added some records.
>>
>> IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set it
>> to 1.
>> Which is correct?
>> I couldn't find the definition about this in the spec.
>> The first value of autoIncrement should be defined in the spec,
>> or the spec should allow us to set the first value of autoIncrement, I think.
>>
>> Sorry in advance if the discussion has already been done.
>> Thank you for your time.
>
> Good catch! This definitely needs to be specified in the spec.
>
> I have a weak preference for using 1. This has a smaller risk of
> triggering edge cases in the client code since it's always truthy.
> I.e. if someone tries to detect the presence of an id, they won't fail
> due to the id being 0.
I agree -- this is also the behavior in all DBMS I've worked with. There's time
for MS to update their implementation. All around win.
Re: Indexed database API autoIncrement
On Sun, Oct 23, 2011 at 4:20 AM, Futomi Hatano wrote:
> Hello everyone,
>
> I'm not a W3C member, can I send a mail to the list?
Absolutely! This is a public list intended for just that!
> I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
> I found a different behavior between the two.
> I set autoIncrement to true when I created a Object Store as below.
>
> var store = db.createObjectStore(store_name, { keyPath: 'id', autoIncrement:
> true });
>
> Then, I added some records.
>
> IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set it
> to 1.
> Which is correct?
> I couldn't find the definition about this in the spec.
> The first value of autoIncrement should be defined in the spec,
> or the spec should allow us to set the first value of autoIncrement, I think.
>
> Sorry in advance if the discussion has already been done.
> Thank you for your time.
Good catch! This definitely needs to be specified in the spec.
I have a weak preference for using 1. This has a smaller risk of
triggering edge cases in the client code since it's always truthy.
I.e. if someone tries to detect the presence of an id, they won't fail
due to the id being 0.
/ Jonas
Re: Indexed database API autoIncrement
On Sun, Oct 23, 2011 at 7:20 AM, Futomi Hatano wrote:
> Hello everyone,
>
> I'm not a W3C member, can I send a mail to the list?
>
Yes, this mailing list is open to anyone.
I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
> I found a different behavior between the two.
> I set autoIncrement to true when I created a Object Store as below.
>
> var store = db.createObjectStore(store_name, { keyPath: 'id',
> autoIncrement: true });
>
> Then, I added some records.
>
> IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set
> it to 1.
> Which is correct?
>
This is a good question. I don't believe that the spec specifies this.
- Kyle
Re: Indexed Database API
On Thu, Mar 17, 2011 at 3:11 PM, Pablo Castro wrote: > > From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On > Behalf Of Jeremy Orlow > Sent: Tuesday, March 15, 2011 3:08 PM > >>> Filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12310 > > I'm not sure if this is a lot more valuable than just creating an index over > whatever index key you want plus the primary key, and then seeking to the > compound key of the last row in the previous page to resume scanning the next > page of records. No strong pushback, just not sure this is worth the extra > method. The use-case here was a paged UI that at the bottom allowed you to go to any page. In this scenario you may not ever visit the page before the one you want to display, and so you don't know which key to jump to. / Jonas
RE: Indexed Database API
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Tuesday, March 15, 2011 3:08 PM >> Filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12310 I'm not sure if this is a lot more valuable than just creating an index over whatever index key you want plus the primary key, and then seeking to the compound key of the last row in the previous page to resume scanning the next page of records. No strong pushback, just not sure this is worth the extra method. -pablo
Re: Indexed Database API
Filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12310 On Fri, Mar 4, 2011 at 5:45 PM, Jeremy Orlow wrote: > On Fri, Mar 4, 2011 at 5:36 PM, Jonas Sicking wrote: > >> A few observations: >> >> 1. It seems like a fairly rare use case to have to jump to item #100 >> without first also observing item 1-99. When showing a paged view >> which lets the user to jump directly to, say, page 5 it can certainly >> happen, but the page could optimize for the case when the user first >> goes through page 1-4. >> 2. Since it's not a common case, adding support for it just on >> cursors, rather than cursors and objectStores, seems enough. Would be >> as simple as adding a .advance (or similarly named function) which >> simply takes an integer. I don't see that we need to support jumping >> in a arbitrary direction since we don't allow continue() in an >> arbitrary direction. >> 3. We do have a bit of a hole in our index-cursor API. While you can >> start the cursor at an arbitrary key, you can only start it at the >> first entry with that key in the case when there are duplicate keys. >> So if you iterate an index 10 records at a time, even if you never >> need to skip any entries, you can't always resume where you left off, >> even if you know the exact key+primaryKey for the record you want to >> resume at. >> > > I agree with all of this reasoning. > > >> 4. While I agree that count() seems like a useful function, my concern >> is that people might think it's a cheap operation. > > > This is my concern with your "getAll" function, btw. :-) > > >> Getting the count >> for a full objectStore or index should be quick, but getting the count >> for a given key range (such as on a cursor) seems like it could be >> expensive. My b-tree knowledge isn't the best, but isn't there a risk >> that you have to linearly walk the full keyrange? Or does b-trees keep >> an exact count of record in each node? Even if linear walking is >> required, there might not be much we can do, and the best we can do is >> to document that this is a slow operation. >> > > I don't think we should limit our thinking to btrees, but it seems as > though implementations could keep track of the number of children under a > particular node, in which case it should be faster than linear. > > COUNT(*) is a very popular function in SQL (even with WHERE clauses). It > seems like there will be some cases where the implementor truly does need a > count but not the data. And given that at least some implementations should > be able to optimize this, I think we should give them an API call. > > J > > On Fri, Mar 4, 2011 at 2:32 PM, Jeremy Orlow wrote: >> > On Fri, Mar 4, 2011 at 1:38 PM, ben turner >> wrote: >> >> >> >> Firefox does lazily deserialize cursor values, so the slowdown you're >> >> noticing is most likely due to us preserving the order of request >> >> callbacks by queuing every continue() call in line with the rest of >> >> the transaction. Jonas had proposed a faster, high performance cursor >> >> that did not respect this ordering, maybe that's all that you'd need. >> >> >> >> However, a few thoughts: >> >> >> >> 1. How do you know Page 5 even exists? We haven't exposed a count() >> >> function yet... >> >> 2. I think we should expose a count() function! >> >> 3. Maybe we should expose a getAt(long index, direction); >> >> function on indexes and objectStores? >> > >> > A count function might make sense. >> > But in this case, you could just jump forward to page 5 and see if you >> get >> > an error or not. >> > I'd lean towards just adding jumping forward to cursors for now though. >> If >> > getting a single item at some position is popular, then we can always >> add >> > it. >> > Let's avoid adding prioritization of cursor.continue calls unless we >> have >> > absolutely no other choice. >> > J >> >> >> >> On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay >> >> wrote: >> >> > On 03/02/2011 09:02 AM, Ben Dilts wrote: >> >> >> >> >> >> Why is there no mechanism for paging results, a la SQL's "limit"? >> If I >> >> >> want entries in positions 140-159 from an index, I have to call >> >> >> continue() on a cursor 139 times, which in turn unserializes 139 >> >> >> objects >> >> >> from my store that I don't care about, which in FF4 is making a >> lookup >> >> >> in IndexedDB sometimes take many seconds for even a few records. >> >> > >> >> > Sounds like there is something to optimize in the implementation. >> >> > Have you filed a bug >> >> > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core >> >> > component DOM ? >> >> > If not, please do so and attach a *minimal* testcase. >> >> > >> >> > >> >> > Thanks, >> >> > >> >> > >> >> > -Olli >> >> > >> >> > >> >> > It >> >> >> >> >> >> makes no sense--am I just missing something in the spec? >> >> >> >> >> >> >> >> >> Ben Dilts >> >> > >> >> > >> >> >> > >> > >> > >
Re: Indexed Database API
On Fri, Mar 4, 2011 at 5:36 PM, Jonas Sicking wrote: > A few observations: > > 1. It seems like a fairly rare use case to have to jump to item #100 > without first also observing item 1-99. When showing a paged view > which lets the user to jump directly to, say, page 5 it can certainly > happen, but the page could optimize for the case when the user first > goes through page 1-4. > 2. Since it's not a common case, adding support for it just on > cursors, rather than cursors and objectStores, seems enough. Would be > as simple as adding a .advance (or similarly named function) which > simply takes an integer. I don't see that we need to support jumping > in a arbitrary direction since we don't allow continue() in an > arbitrary direction. > 3. We do have a bit of a hole in our index-cursor API. While you can > start the cursor at an arbitrary key, you can only start it at the > first entry with that key in the case when there are duplicate keys. > So if you iterate an index 10 records at a time, even if you never > need to skip any entries, you can't always resume where you left off, > even if you know the exact key+primaryKey for the record you want to > resume at. > I agree with all of this reasoning. > 4. While I agree that count() seems like a useful function, my concern > is that people might think it's a cheap operation. This is my concern with your "getAll" function, btw. :-) > Getting the count > for a full objectStore or index should be quick, but getting the count > for a given key range (such as on a cursor) seems like it could be > expensive. My b-tree knowledge isn't the best, but isn't there a risk > that you have to linearly walk the full keyrange? Or does b-trees keep > an exact count of record in each node? Even if linear walking is > required, there might not be much we can do, and the best we can do is > to document that this is a slow operation. > I don't think we should limit our thinking to btrees, but it seems as though implementations could keep track of the number of children under a particular node, in which case it should be faster than linear. COUNT(*) is a very popular function in SQL (even with WHERE clauses). It seems like there will be some cases where the implementor truly does need a count but not the data. And given that at least some implementations should be able to optimize this, I think we should give them an API call. J On Fri, Mar 4, 2011 at 2:32 PM, Jeremy Orlow wrote: > > On Fri, Mar 4, 2011 at 1:38 PM, ben turner > wrote: > >> > >> Firefox does lazily deserialize cursor values, so the slowdown you're > >> noticing is most likely due to us preserving the order of request > >> callbacks by queuing every continue() call in line with the rest of > >> the transaction. Jonas had proposed a faster, high performance cursor > >> that did not respect this ordering, maybe that's all that you'd need. > >> > >> However, a few thoughts: > >> > >> 1. How do you know Page 5 even exists? We haven't exposed a count() > >> function yet... > >> 2. I think we should expose a count() function! > >> 3. Maybe we should expose a getAt(long index, direction); > >> function on indexes and objectStores? > > > > A count function might make sense. > > But in this case, you could just jump forward to page 5 and see if you > get > > an error or not. > > I'd lean towards just adding jumping forward to cursors for now though. > If > > getting a single item at some position is popular, then we can always add > > it. > > Let's avoid adding prioritization of cursor.continue calls unless we have > > absolutely no other choice. > > J > >> > >> On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay > >> wrote: > >> > On 03/02/2011 09:02 AM, Ben Dilts wrote: > >> >> > >> >> Why is there no mechanism for paging results, a la SQL's "limit"? If > I > >> >> want entries in positions 140-159 from an index, I have to call > >> >> continue() on a cursor 139 times, which in turn unserializes 139 > >> >> objects > >> >> from my store that I don't care about, which in FF4 is making a > lookup > >> >> in IndexedDB sometimes take many seconds for even a few records. > >> > > >> > Sounds like there is something to optimize in the implementation. > >> > Have you filed a bug > >> > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core > >> > component DOM ? > >> > If not, please do so and attach a *minimal* testcase. > >> > > >> > > >> > Thanks, > >> > > >> > > >> > -Olli > >> > > >> > > >> > It > >> >> > >> >> makes no sense--am I just missing something in the spec? > >> >> > >> >> > >> >> Ben Dilts > >> > > >> > > >> > > > > >
Re: Indexed Database API
A few observations: 1. It seems like a fairly rare use case to have to jump to item #100 without first also observing item 1-99. When showing a paged view which lets the user to jump directly to, say, page 5 it can certainly happen, but the page could optimize for the case when the user first goes through page 1-4. 2. Since it's not a common case, adding support for it just on cursors, rather than cursors and objectStores, seems enough. Would be as simple as adding a .advance (or similarly named function) which simply takes an integer. I don't see that we need to support jumping in a arbitrary direction since we don't allow continue() in an arbitrary direction. 3. We do have a bit of a hole in our index-cursor API. While you can start the cursor at an arbitrary key, you can only start it at the first entry with that key in the case when there are duplicate keys. So if you iterate an index 10 records at a time, even if you never need to skip any entries, you can't always resume where you left off, even if you know the exact key+primaryKey for the record you want to resume at. 4. While I agree that count() seems like a useful function, my concern is that people might think it's a cheap operation. Getting the count for a full objectStore or index should be quick, but getting the count for a given key range (such as on a cursor) seems like it could be expensive. My b-tree knowledge isn't the best, but isn't there a risk that you have to linearly walk the full keyrange? Or does b-trees keep an exact count of record in each node? Even if linear walking is required, there might not be much we can do, and the best we can do is to document that this is a slow operation. / Jonas On Fri, Mar 4, 2011 at 2:32 PM, Jeremy Orlow wrote: > On Fri, Mar 4, 2011 at 1:38 PM, ben turner wrote: >> >> Firefox does lazily deserialize cursor values, so the slowdown you're >> noticing is most likely due to us preserving the order of request >> callbacks by queuing every continue() call in line with the rest of >> the transaction. Jonas had proposed a faster, high performance cursor >> that did not respect this ordering, maybe that's all that you'd need. >> >> However, a few thoughts: >> >> 1. How do you know Page 5 even exists? We haven't exposed a count() >> function yet... >> 2. I think we should expose a count() function! >> 3. Maybe we should expose a getAt(long index, direction); >> function on indexes and objectStores? > > A count function might make sense. > But in this case, you could just jump forward to page 5 and see if you get > an error or not. > I'd lean towards just adding jumping forward to cursors for now though. If > getting a single item at some position is popular, then we can always add > it. > Let's avoid adding prioritization of cursor.continue calls unless we have > absolutely no other choice. > J >> >> On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay >> wrote: >> > On 03/02/2011 09:02 AM, Ben Dilts wrote: >> >> >> >> Why is there no mechanism for paging results, a la SQL's "limit"? If I >> >> want entries in positions 140-159 from an index, I have to call >> >> continue() on a cursor 139 times, which in turn unserializes 139 >> >> objects >> >> from my store that I don't care about, which in FF4 is making a lookup >> >> in IndexedDB sometimes take many seconds for even a few records. >> > >> > Sounds like there is something to optimize in the implementation. >> > Have you filed a bug >> > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core >> > component DOM ? >> > If not, please do so and attach a *minimal* testcase. >> > >> > >> > Thanks, >> > >> > >> > -Olli >> > >> > >> > It >> >> >> >> makes no sense--am I just missing something in the spec? >> >> >> >> >> >> Ben Dilts >> > >> > >> > >
Re: Indexed Database API
On Fri, Mar 4, 2011 at 1:38 PM, ben turner wrote: > Firefox does lazily deserialize cursor values, so the slowdown you're > noticing is most likely due to us preserving the order of request > callbacks by queuing every continue() call in line with the rest of > the transaction. Jonas had proposed a faster, high performance cursor > that did not respect this ordering, maybe that's all that you'd need. > > However, a few thoughts: > > 1. How do you know Page 5 even exists? We haven't exposed a count() > function yet... > 2. I think we should expose a count() function! > 3. Maybe we should expose a getAt(long index, direction); > function on indexes and objectStores? > A count function might make sense. But in this case, you could just jump forward to page 5 and see if you get an error or not. I'd lean towards just adding jumping forward to cursors for now though. If getting a single item at some position is popular, then we can always add it. Let's avoid adding prioritization of cursor.continue calls unless we have absolutely no other choice. J On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay > wrote: > > On 03/02/2011 09:02 AM, Ben Dilts wrote: > >> > >> Why is there no mechanism for paging results, a la SQL's "limit"? If I > >> want entries in positions 140-159 from an index, I have to call > >> continue() on a cursor 139 times, which in turn unserializes 139 objects > >> from my store that I don't care about, which in FF4 is making a lookup > >> in IndexedDB sometimes take many seconds for even a few records. > > > > Sounds like there is something to optimize in the implementation. > > Have you filed a bug > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core > > component DOM ? > > If not, please do so and attach a *minimal* testcase. > > > > > > Thanks, > > > > > > -Olli > > > > > > It > >> > >> makes no sense--am I just missing something in the spec? > >> > >> > >> Ben Dilts > > > > > >
Re: Indexed Database API
Firefox does lazily deserialize cursor values, so the slowdown you're noticing is most likely due to us preserving the order of request callbacks by queuing every continue() call in line with the rest of the transaction. Jonas had proposed a faster, high performance cursor that did not respect this ordering, maybe that's all that you'd need. However, a few thoughts: 1. How do you know Page 5 even exists? We haven't exposed a count() function yet... 2. I think we should expose a count() function! 3. Maybe we should expose a getAt(long index, direction); function on indexes and objectStores? -Ben On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay wrote: > On 03/02/2011 09:02 AM, Ben Dilts wrote: >> >> Why is there no mechanism for paging results, a la SQL's "limit"? If I >> want entries in positions 140-159 from an index, I have to call >> continue() on a cursor 139 times, which in turn unserializes 139 objects >> from my store that I don't care about, which in FF4 is making a lookup >> in IndexedDB sometimes take many seconds for even a few records. > > Sounds like there is something to optimize in the implementation. > Have you filed a bug https://bugzilla.mozilla.org/enter_bug.cgi?product=Core > component DOM ? > If not, please do so and attach a *minimal* testcase. > > > Thanks, > > > -Olli > > > It >> >> makes no sense--am I just missing something in the spec? >> >> >> Ben Dilts > >
Re: Indexed Database API
On 03/02/2011 09:02 AM, Ben Dilts wrote: Why is there no mechanism for paging results, a la SQL's "limit"? If I want entries in positions 140-159 from an index, I have to call continue() on a cursor 139 times, which in turn unserializes 139 objects from my store that I don't care about, which in FF4 is making a lookup in IndexedDB sometimes take many seconds for even a few records. Sounds like there is something to optimize in the implementation. Have you filed a bug https://bugzilla.mozilla.org/enter_bug.cgi?product=Core component DOM ? If not, please do so and attach a *minimal* testcase. Thanks, -Olli It makes no sense--am I just missing something in the spec? Ben Dilts
Re: Indexed Database API
On Fri, Mar 4, 2011 at 11:33 AM, Ben Dilts wrote: > Jeremy, > > Thanks for the reply! However, my indices are not typically unique, > contiguous numbers. For example, I have an index on an item's "saved" date, > as a MySQL-style date/time string. These dates are not necessarily unique, > and are certainly not contiguous. So if a user is currently viewing the > first 20 items in this object store, and would like to jump to page 5 (items > 81-100), how would I go about that? I don't know what key value is in the > 81st position in the index. In fact, the key value in position 81 may also > occupy positions 80 and 82--if I skip to that key value, I may end up in a > slightly wrong place. > If you're jumping beyond what you've already looked at, then yeah...the current API is probably not sufficient. I wouldn't mind adding an option to openCursor to start the cursor some number of items forward of the first element in the key range. I also wouldn't mind adding some sort of "jumpForward" method to IDBCursor. J > On Fri, Mar 4, 2011 at 11:33 AM, Jeremy Orlow wrote: > >> On Tue, Mar 1, 2011 at 11:02 PM, Ben Dilts wrote: >> >>> Why is there no mechanism for paging results, a la SQL's "limit"? If I >>> want entries in positions 140-159 from an index, I have to call continue() >>> on a cursor 139 times, which in turn unserializes 139 objects from my store >>> that I don't care about, which in FF4 is making a lookup in IndexedDB >>> sometimes take many seconds for even a few records. It makes no sense--am I >>> just missing something in the spec? >> >> >> Just use cursor.continue() with a key parameter to skip the cursor ahead >> to where you care about. >> >> J >> > >
Re: Indexed Database API
Jeremy, Thanks for the reply! However, my indices are not typically unique, contiguous numbers. For example, I have an index on an item's "saved" date, as a MySQL-style date/time string. These dates are not necessarily unique, and are certainly not contiguous. So if a user is currently viewing the first 20 items in this object store, and would like to jump to page 5 (items 81-100), how would I go about that? I don't know what key value is in the 81st position in the index. In fact, the key value in position 81 may also occupy positions 80 and 82--if I skip to that key value, I may end up in a slightly wrong place. Ben Dilts On Fri, Mar 4, 2011 at 11:33 AM, Jeremy Orlow wrote: > On Tue, Mar 1, 2011 at 11:02 PM, Ben Dilts wrote: > >> Why is there no mechanism for paging results, a la SQL's "limit"? If I >> want entries in positions 140-159 from an index, I have to call continue() >> on a cursor 139 times, which in turn unserializes 139 objects from my store >> that I don't care about, which in FF4 is making a lookup in IndexedDB >> sometimes take many seconds for even a few records. It makes no sense--am I >> just missing something in the spec? > > > Just use cursor.continue() with a key parameter to skip the cursor ahead to > where you care about. > > J >
Re: Indexed Database API
On Tue, Mar 1, 2011 at 11:02 PM, Ben Dilts wrote: > Why is there no mechanism for paging results, a la SQL's "limit"? If I > want entries in positions 140-159 from an index, I have to call continue() > on a cursor 139 times, which in turn unserializes 139 objects from my store > that I don't care about, which in FF4 is making a lookup in IndexedDB > sometimes take many seconds for even a few records. It makes no sense--am I > just missing something in the spec? Just use cursor.continue() with a key parameter to skip the cursor ahead to where you care about. J
Re: Indexed Database API is the new title [Was: Renaming WebSimpleDB]
On Dec 2, 2009, at 9:51 AM, Arthur Barstow wrote: Hi All, On Nov 30, 2009, at 11:20 AM, ext Michael(tm) Smith wrote: Hi Nikunj, @2009-11-26 02:00 -0800: Here's my suggestion: 1. WebDatabase be renamed to WebSQLDatabase 2. WebSimpleDB be renamed to ISAM Database Level 1 Thanks for all of the good feedback. The new title of the WebSimpleDB spec is: Indexed Database API I have updated this in the ED. Thanks all for weighing in. Nikunj http://o-micron.blogspot.com
