[
https://issues.apache.org/jira/browse/DERBY-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim Haase updated DERBY-4719:
-----------------------------
Component/s: (was: Documentation)
Removing Documentation from the affected components list, since the remaining
parts of this task seem to be of low priority and a separate doc issue could be
filed if the work is completed.
> Define consistent Derby data source behavior
> --------------------------------------------
>
> Key: DERBY-4719
> URL: https://issues.apache.org/jira/browse/DERBY-4719
> Project: Derby
> Issue Type: Task
> Components: Javadoc, JDBC, Network Client
> Affects Versions: 10.7.1.1
> Reporter: Kristian Waagan
> Labels: derby_triage10_9
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
