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

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.


On Wed, 10 Oct 2007, Brady Eidson wrote:
>
> openDatabase() is called with a database name and an expected version 
> string.
> 
> If the database has a version, and it is different than the expected 
> version, openDatabase() fails.  This makes sense.  But...
> 
> "Otherwise, if the database version is the empty string, or if the 
> database doesn't yet exist, or if the database exists and the version 
> provided to the openDatabase() method is the same as the current version 
> associated with the database, then the method must return a Database 
> object..."
> 
> 1 of these 3 situations doesn't make sense.  A database without a 
> version should not be considered valid if the caller to openDatabase() 
> expects a version.

Yeah, that should have been "if the expected version is the empty string".

Fixed.


On Thu, 11 Oct 2007, Scott Hess wrote:
> 
> Actually, I don't quite understand why simply having the empty string be 
> a version isn't sufficient.  If you don't want to bother with 
> versioning, always use the empty string (or make the parameter 
> optional).  If you do want versioning, then it's likely that you don't 
> want the versioning to be advisory, which is what allowing the empty 
> string to match anything does.

The idea is that you might not know what the version is (say, because some 
rogue code changed the version to a random string), and you want to go in 
and fix it. You need a way in.


> It may be worthwhile to allow the version to be an array.  Then the app 
> could easily say "Open this database, and here is the set of versions I 
> understand."  That operation could be wrapped in a helper function which 
> runs through the open calls catching exceptions, but it seems like 
> something reasonable to just bake into the API, because if you have 
> database versioning, you're almost certainly going to have multiple 
> outstanding database versions (unlike with a server-side app, you have 
> little control over when a client executes your app).

We could do that. I'm a little wary of adding arrays everywhere though. 
What do other people think? Is this worthwhile?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 17 October 2007 00:47:10 UTC