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

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.

J

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
>