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

[Shawn Wilsher]

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.

Cheers,

Shawn

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.

smime.p7s
Description: S/MIME Cryptographic Signature