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

On 9/29/2010 6:12 AM, Jeremy Orlow wrote:
> 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?
I think (2) is most consistent with how transactions work in other 
places.  I think it's sane too.  I can't come up with a good reason why 
we'd throw for subsequent setVersion calls either.

Thinking about it some more, this might make sense for someone who has 
had more than one version change.  They could first update the the 
version from "1" to "2", and then from "2" to "3".  Since it's possible 
that clients visiting the site could be on any of these three versions, 
it makes sense to have functions that only go from the previous version 
to the next, otherwise you'll end up with lots of logic to deal with 
every version combination.  Doing this all in the same transaction seems 
to make sense to me.

Cheers,

Shawn