Kathey Marsden wrote:
I'll analyze some usage scenarios that I am aware of and see what the
impact might be. The most important thing is that this be a
deliberate choice and that we not rush new functionality and
introduce a regression where there is a reasonable technical
alternative,
Olav Sandstaa wrote:
Kathey Marsden wrote:
3) If derby booted at the first connection or the first instantiation
of the driver (whichever came first) , would that solve the
derby.drda.startNetworkServer problem.
This depends on what you mean by the first instantiation of the
driver.
Rick Hillegas wrote:
1) Remove the JDBC4-driver-autoloading. This removes a useful
ease-of-development feature and makes us fail to be JDBC4-compliant.
2) Don't boot the engine when registering the embedded driver. Instead,
boot the engine the first time that someone requests an embedded
Rick Hillegas and Kathey Marsden wrote:
[lots of stuff about implementation details that probably should wait a bit]
I think Dan's summary and focus on goals was good:
Dan said ...
I think the goal should be to support auto-loading and to ensure
applications that perform some setup and then
Kathey Marsden wrote:
Rick Hillegas and Kathey Marsden wrote:
[lots of stuff about implementation details that probably should wait
a bit]
I think Dan's summary and focus on goals was good:
Dan said ...
I think the goal should be to support auto-loading and to ensure
applications that
Kathey Marsden wrote:
David Van Couvering wrote:
- Log a bug
- Work on fixing it by booting on first connection rather than when
the driver is loaded.
It would be good to get input from the user community as well. One
possible approach would be to log the bug, mark it as a regression,
Jean T. Anderson wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
David Van Couvering wrote:
- Log a bug
- Work on fixing it by booting on first connection rather than when
the driver is loaded.
It would be good to get input from the user community as well. One
Kathey Marsden wrote:
Rick Hillegas wrote:
I'm afraid I don't understand why we would want to revert our tests
to the old behavior. It seems to me that our tests are practicing
stunts which we strongly discourage: changing Derby properties on the
fly. In general, there will always be
Rick Hillegas wrote:
Jean T. Anderson wrote:
Rick Hillegas wrote:
...
Does the precedence for properties documentation need to be updated to
mention jdbc 4/jdk 1.6 behavior?
http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html
I don't see that the precedence of properties has
Jean T. Anderson wrote:
Rick Hillegas wrote:
Jean T. Anderson wrote:
Rick Hillegas wrote:
...
Does the precedence for properties documentation need to be updated to
mention jdbc 4/jdk 1.6 behavior?
http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html
I don't see that the
Rick Hillegas wrote:
This topic was raised in an earlier email thread
(http://comments.gmane.org/gmane.comp.apache.db.derby.devel/20899) but
it does not appear that we agreed on a solution. I would like to re-open
this topic and hopefully we can converge on how we want to handle this
issue.
David Van Couvering wrote:
- Log a bug
- Work on fixing it by booting on first connection rather than when
the driver is loaded.
It would be good to get input from the user community as well. One
possible approach would be to log the bug, mark it as a regression,
existing application
This topic was raised in an earlier email thread
(http://comments.gmane.org/gmane.comp.apache.db.derby.devel/20899) but
it does not appear that we agreed on a solution. I would like to re-open
this topic and hopefully we can converge on how we want to handle this
issue.
Olav has analyzed a
My vote:
- Document it for 10.2
- Log a bug
- Work on fixing it by booting on first connection rather than when the
driver is loaded.
-1 on removing the autoloading feature, unless people have evidence that
this is going to cause real problems for our users.
David
Rick Hillegas wrote:
14 matches
Mail list logo
