Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <24164206.115691277823110980.JavaMail.jira@thor>
Date: Tue, 29 Jun 2010 10:51:50 -0400 (EDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4719) Define consistent Derby data source
 behavior
In-Reply-To: <15654910.90201277730469835.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883571#action_12883571 ] 

Rick Hillegas commented on DERBY-4719:
--------------------------------------

Thanks, Kristian. Some more commentary:

i') Can we state what the client vs. engine attributes are? That is, the attributes which the client would bother to parse? Are they just the attributes which have explicit setters?

ii') I think you are saying that with a little re-factoring the DataSource could know the legal values for the attributes which it bothers to parse.

iii') I like your suggestion that explicit setters should always trump the attributes in the connection string. That's easy to understand and probably more straightforward for configurations which are declared in xml. I don't know how to help the admin GUIs. Whatever rule we choose is going to be hidden by the GUI. I wouldn't bother sanding down that case.

It sounds like we are converging on a set of behaviors which will let you fix DERBY-4067 soon. Thanks.


> 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.