[
https://issues.apache.org/jira/browse/DERBY-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883494#action_12883494
]
Kristian Waagan commented on DERBY-4719:
----------------------------------------
Hi Rick.
Some more comments below.
Rick> i) The connection attribute string should be parsed by all of the
DataSources and its directives should be followed.
Note that only a small subset of the allowed attributes in the attribute string
is parsed. This subset differs between client and embedded, since many of the
attributes only make sense in a client/server environment.
I think we are doing the right thing here - parse only attributes the data
source understands and leave the rest to the engine.
Rick > ii) Derby should raise an exception (or at least a warning) if an
attribute is set to an illegal value.
Again, this will only be true for the attributes parsed. Other attributes may
be parsed by the engine, which may in turn throw an exception when the
connection is made.
There is one complication: in some cases the data source doesn't know the set
of valid values.
I guess it would be okay to add knowledge about the current client driver's
capabilities in the data source, as the data source is part of the client
driver (i.e. if you want to use new client driver features you should also get
a connection through a data source of the same version).
Rick> iii) In the case where conflicting values are specified for an attribute
(e.g., one value is specified in the connection string and another value is
specified in an explicit setter method), then the most recent specification
should prevail.
When looking at the data source definition in an appserver admin GUI, or just
the XML definition, how would you know in which order the setter and the
attribute string would be applied?
Does this scenario warrant a different rule? (i.e. the setter trumps the
attribute string [1]).
I think both solutions would work fine with respect to new setters and/or
attributes being added to a data source.
In any case, I think addressing i) is of great importance (DERBY-4067, client
side only). I think it can be backported (at least back to 10.5, probably
further).
We can then change all data sources to agree with whatever we decide in Derby
10.7.
Does this sound like a useful first step we can implement right away?
Thanks,
[1] More details to discuss here...
> 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.
