You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kristian Waagan <Kr...@Sun.COM> on 2010/05/27 13:21:24 UTC
Derby data sources
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,
--
Kristian
Re: Derby data sources
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
On 05/27/10 01:21 PM, Kristian Waagan wrote:
> 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'm leaning towards 1a, since using the supplied attributes sounds more
intuitive. I don't find 1b very attractive (silently ignoring an
attribute, even if done consistently across the data sources, will still
confuse the users), so 1c would be my second choice.
--
Knut Anders
Re: Derby data sources
Posted by Rick Hillegas <ri...@oracle.com>.
Kristian Waagan wrote:
> On 28.05.10 16:03, Rick Hillegas wrote:
>> Hi Kristian,
>>
>> Thanks for your detailed explanation of this bizarre and confusing
>> behavior. I can imagine that this inconsistency is very frustrating
>> to our users.
>>
>> Each of the options you are considering will create backward
>> compatibility problems for some applications. I agree with Knut that
>> silent behavior changes are worse than noisy ones. I think that we
>> could talk ourselves into an incompatible behavior change if the
>> javadoc explicitly says that the behavior is undefined.
>>
>> However, I don't see much value in moving from one inconsistent
>> behavior to another. If we want to tackle this confusion, then I
>> would recommend that we define the behavior explicitly in the javadoc
>> and make all of the DataSources conform to the defined behavior.
>>
>> So my advice would be to not touch the code yet. Instead, file a JIRA
>> based on your detailed explanation of the problem. Then let the
>> community discuss what the best solution is.
>
> Hi Rick,
>
> Finally took the time to create a Jira for this :)
> See DERBY-4719 [1].
>
>
> Regards,
Thanks.
Re: Derby data sources
Posted by Kristian Waagan <Kr...@Sun.COM>.
On 28.05.10 16:03, Rick Hillegas wrote:
> Hi Kristian,
>
> Thanks for your detailed explanation of this bizarre and confusing
> behavior. I can imagine that this inconsistency is very frustrating to
> our users.
>
> Each of the options you are considering will create backward
> compatibility problems for some applications. I agree with Knut that
> silent behavior changes are worse than noisy ones. I think that we
> could talk ourselves into an incompatible behavior change if the
> javadoc explicitly says that the behavior is undefined.
>
> However, I don't see much value in moving from one inconsistent
> behavior to another. If we want to tackle this confusion, then I would
> recommend that we define the behavior explicitly in the javadoc and
> make all of the DataSources conform to the defined behavior.
>
> So my advice would be to not touch the code yet. Instead, file a JIRA
> based on your detailed explanation of the problem. Then let the
> community discuss what the best solution is.
Hi Rick,
Finally took the time to create a Jira for this :)
See DERBY-4719 [1].
Regards,
--
Kristian
[1] https://issues.apache.org/jira/browse/DERBY-4719
>
> Thanks,
> -Rick
>
>
>
> Kristian Waagan wrote:
>> 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,
>
Re: Derby data sources
Posted by Rick Hillegas <ri...@oracle.com>.
Hi Kristian,
Thanks for your detailed explanation of this bizarre and confusing
behavior. I can imagine that this inconsistency is very frustrating to
our users.
Each of the options you are considering will create backward
compatibility problems for some applications. I agree with Knut that
silent behavior changes are worse than noisy ones. I think that we could
talk ourselves into an incompatible behavior change if the javadoc
explicitly says that the behavior is undefined.
However, I don't see much value in moving from one inconsistent behavior
to another. If we want to tackle this confusion, then I would recommend
that we define the behavior explicitly in the javadoc and make all of
the DataSources conform to the defined behavior.
So my advice would be to not touch the code yet. Instead, file a JIRA
based on your detailed explanation of the problem. Then let the
community discuss what the best solution is.
Thanks,
-Rick
Kristian Waagan wrote:
> 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,