Re: [whatwg] SQL API - SQLVersionChangeCallback vs SQLTransactionCallback
On Thu, 25 Oct 2007, Dimitri Glazkov wrote: > > I may be completely alone in this one, but is schema versioning as part > of the API really a necessary thing? I mean, it's convenient, but is it > necessary? Just trying to keep it simple. In particular with the offline stuff, it is highly likely that code will be running and interacting with the database in one window when a script tries to update the schema, and we don't want authors to have to implement some primitive locking facility of their own to prevent old versions corrupting the data. I think it's relatively light-weight yet provides something that could end up being really useful in certain cases. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SQL API - SQLVersionChangeCallback vs SQLTransactionCallback
On Thu, 25 Oct 2007, Brady Eidson wrote: > > changeVersion() takes SQLVersionChangeCallback and SQLTransactionErrorCallback > arguments. > transaction() takes SQLTransactionCallback and SQLTransactionErrorCallback > arguments. > > SQLVersionChangeCallback and SQLTransactionCallback have identical properties. Yeah, this is a historical artefact (in one revision, they had different return types). Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SQL API - SQLVersionChangeCallback vs SQLTransactionCallback
On 10/25/07, Brady Eidson <[EMAIL PROTECTED]> wrote: > changeVersion() takes SQLVersionChangeCallback and > SQLTransactionErrorCallback arguments. > transaction() takes SQLTransactionCallback and > SQLTransactionErrorCallback arguments. > > SQLVersionChangeCallback and SQLTransactionCallback have identical > properties. > > It is understood that a changeVersion() chain opens a transaction to > perform your version change with, and besides the additional pre/post > flight steps regarding the version change it operates the same as a > transaction() chain. > > I don't see the point of having a differentiated > SQLVersionChangeCallback when SQLTransactionErrorCallback is good > enough for the error case of changeVersion(). I propose we drop > SQLVersionChangeCallback and modify the full signiture of > changeVersion from: > void changeVersion(in DOMString oldVersion, in DOMString newVersion, > in SQLVersionChangeCallback callback, in SQLTransactionErrorCallback > errorCallback); > to: > void changeVersion(in DOMString oldVersion, in DOMString newVersion, > in SQLTransactionCallback callback, in SQLTransactionErrorCallback > errorCallback); I may be completely alone in this one, but is schema versioning as part of the API really a necessary thing? I mean, it's convenient, but is it necessary? Just trying to keep it simple. :DG<
[whatwg] SQL API - SQLVersionChangeCallback vs SQLTransactionCallback
changeVersion() takes SQLVersionChangeCallback and SQLTransactionErrorCallback arguments. transaction() takes SQLTransactionCallback and SQLTransactionErrorCallback arguments. SQLVersionChangeCallback and SQLTransactionCallback have identical properties. It is understood that a changeVersion() chain opens a transaction to perform your version change with, and besides the additional pre/post flight steps regarding the version change it operates the same as a transaction() chain. I don't see the point of having a differentiated SQLVersionChangeCallback when SQLTransactionErrorCallback is good enough for the error case of changeVersion(). I propose we drop SQLVersionChangeCallback and modify the full signiture of changeVersion from: void changeVersion(in DOMString oldVersion, in DOMString newVersion, in SQLVersionChangeCallback callback, in SQLTransactionErrorCallback errorCallback); to: void changeVersion(in DOMString oldVersion, in DOMString newVersion, in SQLTransactionCallback callback, in SQLTransactionErrorCallback errorCallback); Thanks, ~Brady
