Re: [whatwg] SQL API and changeVersion() with no callbacks

[Aaron Boodman]

On Thu, Oct 25, 2007 at 4:43 PM, Brady Eidson <[EMAIL PROTECTED]> wrote:
> > I added it for the same reason we have executeSql() with no callbacks. I
> > can remove it if desired. I expected it to be used in cases where you want
> > to change the version (e.g. from '' to '1.0') without changing the schema,
> > but where you simply don't really have any good thing to do if it goes
> > wrong. I can remove it if you don't think it'll be important, but then we
> > might as well remove the one with just the first callback, since I can
> > definitely see use cases for changing the version number without doing
> > anything else.
>
>  For the sake of simplicity in the API, I see no reason why there couldn't
> be a single version of changeVersion() with the 2 strings and 2 callbacks.
> Then if a user truly wanted to call changeVersion() but wasn't interested in
> the results, they could just pass null for both of the callbacks.  I suppose
> the same could be said about executeSql().
>
>  But that might go against some DOM'ey or Javascript'ey convention that I'm
> not familiar with.
>
>  I don't feel all too strongly about this.

Sorry I'm (really) late on this.

Anyway, I think these two callbacks should be optional. For several reasons:

1. It's basically the same API as transaction(), so I feel like it
should be consistent.

2. I feel like if an argument allows null, then it is logically
optional. It feels cleaner to me that it is actually optional as well.
That is, it seems arbitrary to me that sometimes in the database api
"optional" arguments can either be unspecified or null, but sometimes
they have to be specified and null.

3. It seems like a valid use case to me to not have an error handler.
This isn't in the spec, but I had assumed that unhandled database
errors would end up calling window.onerror, and then bubbling to the
console, if the UA has one. It's pretty common in JS to not handle
every single error, but instead allow unexpected errors to bubble to
window.onerror and log them there. This is what gmail does for
example. It would be unfortunate to have to have an error handle there
just to immediately rethrow so that you don't lose any information.

Brady, do any of these help convince you at all?

Sorry for resuming this old thread,

- a

Re: [whatwg] SQL API and changeVersion() with no callbacks

[Anne van Kesteren]

On Sat, 27 Oct 2007 00:23:57 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:

I suppose the same could be said about executeSql().


Well... I can certainly see people queuing up a bunch of requests and
dealing with the errors at the end in the transaction error handler. I am
open to requiring that that have an explicit "null" though. Who do other
people think?


There at least some feedback from the developer community that they'd like  
to see optional arguments:


  http://www.dustindiaz.com/dom-interfaces-suck/


--
Anne van Kesteren

Re: [whatwg] SQL API and changeVersion() with no callbacks

[Brady Eidson]

On Oct 26, 2007, at 3:23 PM, Ian Hickson wrote:


On Thu, 25 Oct 2007, Brady Eidson wrote:


For the sake of simplicity in the API, I see no reason why there
couldn't be a single version of changeVersion() with the 2 strings  
and 2

callbacks.  Then if a user truly wanted to call changeVersion() but
wasn't interested in the results, they could just pass null for  
both of

the callbacks.


Very good point. I have removed the overloads here. This is not  
going to

be frequently called, so why not require the callbacks.



I suppose the same could be said about executeSql().


Well... I can certainly see people queuing up a bunch of requests and
dealing with the errors at the end in the transaction error handler.  
I am
open to requiring that that have an explicit "null" though. Who do  
other

people think?


I'm glad there's agreement on changeVersion() and that it has been  
changed.


I wanted to raise the executeSql() point for discussion, not because I  
feel strongly about it.  I agree that queueing up a bunch of queries  
then dealing with the error at the end is a realistic use case.


~Brady

Re: [whatwg] SQL API and changeVersion() with no callbacks

[Ian Hickson]

On Thu, 25 Oct 2007, Brady Eidson wrote:
> 
> For the sake of simplicity in the API, I see no reason why there 
> couldn't be a single version of changeVersion() with the 2 strings and 2 
> callbacks.  Then if a user truly wanted to call changeVersion() but 
> wasn't interested in the results, they could just pass null for both of 
> the callbacks.

Very good point. I have removed the overloads here. This is not going to 
be frequently called, so why not require the callbacks.


> I suppose the same could be said about executeSql().

Well... I can certainly see people queuing up a bunch of requests and 
dealing with the errors at the end in the transaction error handler. I am 
open to requiring that that have an explicit "null" though. Who do other 
people think?

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

Re: [whatwg] SQL API and changeVersion() with no callbacks

[Brady Eidson]

On Oct 25, 2007, at 3:53 PM, Ian Hickson wrote:


On Thu, 25 Oct 2007, Brady Eidson wrote:


One of the changeVersion variants is -

void changeVersion(in DOMString oldVersion, in DOMString newVersion);

This allows an asynchronous version change with no way at all to
determine success or failure of the operation.

I'm just curious what the motivation is.  Is it necessary to support
this?


I added it for the same reason we have executeSql() with no  
callbacks. I
can remove it if desired. I expected it to be used in cases where  
you want
to change the version (e.g. from '' to '1.0') without changing the  
schema,

but where you simply don't really have any good thing to do if it goes
wrong. I can remove it if you don't think it'll be important, but  
then we

might as well remove the one with just the first callback, since I can
definitely see use cases for changing the version number without doing
anything else.


For the sake of simplicity in the API, I see no reason why there  
couldn't be a single version of changeVersion() with the 2 strings and  
2 callbacks.  Then if a user truly wanted to call changeVersion() but  
wasn't interested in the results, they could just pass null for both  
of the callbacks.  I suppose the same could be said about executeSql().


But that might go against some DOM'ey or Javascript'ey convention that  
I'm not familiar with.


I don't feel all too strongly about this.

Thanks,
~Brady

Re: [whatwg] SQL API and changeVersion() with no callbacks

[Ian Hickson]

On Thu, 25 Oct 2007, Brady Eidson wrote:
>
> One of the changeVersion variants is -
> 
> void changeVersion(in DOMString oldVersion, in DOMString newVersion);
> 
> This allows an asynchronous version change with no way at all to 
> determine success or failure of the operation.
> 
> I'm just curious what the motivation is.  Is it necessary to support 
> this?

I added it for the same reason we have executeSql() with no callbacks. I 
can remove it if desired. I expected it to be used in cases where you want 
to change the version (e.g. from '' to '1.0') without changing the schema, 
but where you simply don't really have any good thing to do if it goes 
wrong. I can remove it if you don't think it'll be important, but then we 
might as well remove the one with just the first callback, since I can 
definitely see use cases for changing the version number without doing 
anything else.

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

[whatwg] SQL API and changeVersion() with no callbacks

[Brady Eidson]

One of the changeVersion variants is -

void changeVersion(in DOMString oldVersion, in DOMString newVersion);

This allows an asynchronous version change with no way at all to  
determine success or failure of the operation.


I'm just curious what the motivation is.  Is it necessary to support  
this?


Thanks,
~Brady