db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Wilder <0505...@acadiau.ca>
Subject Re: Bug tracking for the 10.1.2 release
Date Fri, 16 Sep 2005 12:51:45 GMT
Kathey Marsden wrote:

>Philip Wilder wrote:
>  
>
>>Hi Kathey,
>>
>>I'm afraid Derby-406 and Derby-410 have be stagnating. While the
>>original issue was resolved there still exists the issue of setting
>>the properties to null. You'll see that I have released these issues
>>as I have little time to devote to Derby development at present.
>>    
>>
>
>Thanks for the update Philip.
>
>I think it is important for the release notes to show what has been  
>fixed in 10.1.2.
>Would you mind reassigning yourself and marking these resolved and then
>opening a new issue for what is left to be done?   
>
>Thanks
>
>Kathey
>  
>

I took another look at the problems just to refresh my mind as to what 
the remaining concerns were and here is what I found. This is Dan's 
comment in regards to the patch submitted for these issues:

"I do not believe that this patch fully addresses these issues so they 
should not be closed, though it is good progress.
My concern is about the concept of defaults for DataSource properties, 
in these cases

406 - user - default of APP
409 - connectionAttributes - default of empty string
410 - serverName - default of localhost

All these properties are set to the default when the object is created, 
however if the values are set to null
(e.g. setConnecitonAttributes(null)) then should their values revert to 
the default or remain at null?
Existing data sources do not have any properties that have a default.

In the case that the property remains at null, then tests would be 
needed to ensure null is handled correctly,
at least for connectionAttributes I think a NullPointerException will 
occur."

A few tests yield the following results:

    Setting the username to null provides the following error message:
    org.apache.derby.client.am.SqlException: null userid not supported

    Setting the server name to null provides the following error message:
    org.apache.derby.client.am.DisconnectException: Required property
    "serverName" not set

    Setting connection attributes to null simply means that the
    connectionAttributes String is not processed at all. No
    NullPointerExceptions that I could find.


If we want to allow these values to be set to null these strike me as 
suitable error messages and no further work need be done. If we want 
them to revert to their default values that should also be fairly 
trivial to set up.

I guess the real issue here is just making the decision and it might as 
well be now rather then setting up a seperate jira issue to deal with it 
later.

Philip

Mime
View raw message