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
