W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 17 Oct 2007 01:50:51 -0700
Message-ID: <4EC97B65-0B8F-4336-AE83-070FD6DC1F6C@apple.com>

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

>
>> 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.

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.

Regards,
Maciej
Received on Wednesday, 17 October 2007 01:50:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC