[whatwg] several messages about the versioning feature in the SQL API

[Brady Eidson]

On Oct 17, 2007, at 12:47 AM, Ian Hickson wrote:

> On Fri, 5 Oct 2007, Brady Eidson wrote:
>>
>> I think `bool changeVersion()` has a deficient design, and the  
>> content
>> of its description - combined with the lack of clarity around  
>> "active"
>> and "open" transactions - makes implementing it even more dubious.
>>
>> First off, it is synchronous.
>
> Fixed.
>
>> But I also have some confusion about the actual intention of the  
>> method.
>> The line that is the source of most confusion - "When the method is
>> invoked, the user agent must obtain a full lock of the database  
>> (waiting
>> for all open transactions to be closed), and then must verify that  
>> the
>> current version of the database matches the first argument to the
>> method."
>>
>> It's easy to read this line as stating that changeVersion() needs to
>> block waiting for all nested levels of executeSql() and their  
>> callbacks
>> to complete, which seems nonsensical.
>
> Actually that's what we want -- the method is intended for when you  
> want
> to change the schema of the database. First you want to wait for all
> outstanding changes to be committed, and then you want the schema to  
> be
> changed.

My problem with the above was primarily that changeVersion was  
synchronous, which is what made it "nonsensical".  Now that it's  
async, I understand completely.  However...


On Oct 17, 2007, at 1:50 AM, Maciej Stachowiak wrote:

> I think the remaining problem is that you can't make the version  
> change atomic with the transaction you use to actually upgrade the  
> schema. This could be fixed by making changeVersion() open a  
> transaction which is the current transaction during its callback,  
> with the requirement that the version is automatically rolled back  
> if the transaction is. Then you can do the actual schema upgrade  
> from changeVersion()'s callback. I believe this is reasonable to  
> implement and would make database upgrades more sound.

I share Maciej's concern here.  Right now the only alternative is to  
make sure you're not in the middle of any transactions, perform an  
executeSql() chain in one transaction that changes the database  
schema, and immediately follow up that chain with a changeVersion().   
Problem is that another browsing context can still butt-in between  
your schema-mutating-transaction and your call to changeVersion().   
What if that other browsing context changes the schema in a different  
way, then you change the version, but not to what you would expect?

I think there is a legitimate need to make sure a changeVersion() is  
associated with a specific transaction such that when that transaction  
is complete and committed, the version change is attached as part of it.

~Brady