W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] Calling setVersion while already in a setVersion transaction

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 30 Sep 2010 10:16:44 +0100
Message-ID: <AANLkTikPZWW0N-TJNHnc4ejdfWAR2uDrYVVCg9S4w5OU@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: public-webapps WG <public-webapps@w3.org>
Hm.  Actually, I think I like Jonas' proposal better than 1 or 2 (and Shawn,
I see your point about why 2 is better than 1).  I also think that Shawn's
example of doing multiple schema upgrades should still work 3 since we fire
onsuccesses in the order that items were queued up.

Will file a bug in a day or two if no other comments.


On Wed, Sep 29, 2010 at 10:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Sep 29, 2010 at 6:12 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > What should we do when setVersion is called while a setVersion
> transaction
> > is currently active?
> > Off the top of my head, I can think of two behaviors we might want to
> spec:
> >  1) Have the subsequent setVersion simply throw an error.  2) Have the
> > subsequent setVersion adopt the existing setVersion transaction and
> change
> > the version.  (i.e. whatever the last setVersion call sets as the version
> > string will win.)  Any others?  What do you guys think is the most sane
> > behavior?
> My initial reaction was
> 3) Schedule another version transaction which is started after the
> currently running version transaction (and any other already scheduled
> transactions) are done running.
> That was actually my initial reaction, though that is biased by what
> our implementation naturally would do unless special care is taken to
> do something else.
> In general I don't feel strongly either way and am fine with all
> currently proposed solutions.
> / Jonas
Received on Thursday, 30 September 2010 09:18:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC