Define consistent Derby data source behavior
--------------------------------------------

                 Key: DERBY-4719
                 URL: https://issues.apache.org/jira/browse/DERBY-4719
             Project: Derby
          Issue Type: Task
          Components: Documentation, Javadoc, JDBC, Network Client
    Affects Versions: 10.7.0.0
            Reporter: Kristian Waagan


The behavior of the various data source implementations in Derby isn't 
consistent.

As a starting point, from the thread [1] on derby-dev:
-----
Hi,

I have been investigating how the various Derby data source implementations 
behave when it comes to [bean] properties.
Properties and attributes are used interchangeably, and I'll be using the 
following abbreviations:
 o DS-[E|C] the "normal" data souce embedded/client
 o CP-[E|C] ConnectionPoolDataSource embedded/client
 o XA-[E|C] XADataSource embedded/client

Here are some of the current issues:
 1) CP-C and XA-C effectively ignore the connection attribute string for 
certain attributes (those who have individual setters, DERBY-4067)
 2) *-E don't update the internal property state based on the connection 
attribute string (i.e. specifying ";user=myuser" won't change the return value 
of getUser() after connect).
 3) Only some of the properties are updated from the connection attribute 
string. This is as expected, but it is confusing that for instance 
'traceDirectory' is updated and 'traceLevel' isn't.
 4) *-C has 'APP' as the default user, *-E has <null>.
 5) Some property setters accept all values, others throw an exception if the 
value is invalid.


I don't think all these issues should be fixed, but I'd like to fix (1), as it 
has caused some trouble in the past (i.e., user not understanding why the 
settings aren't taking effect).
There are several possible fixes for (1):
 1a) Make CP-C and XA-C process the connection attribute string to update the 
internal state.
 1b) Make DS-C ignore the connection attribute string (may break existing 
deployments).
 1c) Throw exception if a property with a setter is specified in the connection 
attribute string.

I don't care that much about which solution is chosen, but I'd prefer that the 
various data sources are consistent. For instance, it would be nice if a user 
could swap ClientDataSource with ClientConnectionPoolDataSource without having 
to change the data source definition. For instance, doing this today with 
"ssl=basic" in the connection attribute string would make DS-C connect with 
SSL, but CP-C would connection without SSL.

We have this wording in the JavaDoc for 
ClienBaseDataSource.setConnectionAttributes(String):
"Set this property to pass in more Derby specific connection URL attributes.
Any attributes that can be set using a property of this DataSource 
implementation (e.g user, password) should not be set in connectionAttributes. 
Conflicting settings in connectionAttributes and properties of the DataSource 
will lead to unexpected behaviour."


Any opinions or questions on any of this?


Regards, 
-----

[1] http://old.nabble.com/Derby-data-sources-to28692616.html#a28692616

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to