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 Andrew McIntyre <mc...@gmail.com> on 2005/05/18 04:17:10 UTC
Planning for a 10.1 release
Hello derby-dev,
Now that there have been some significant new contributions to Derby
since 10.0.2.1 was released, I think we should begin planning for a
10.1 release. As promised earlier, I'll volunteer to be release
manager. So, here goes:
1) Are there any new features or significant bugfixes near completion
that should be in the 10.1 release? Dan mentioned that he would like
to have his JSR-169 work included, Tomohito's fix for Derby-167 looks
nearly complete, and David V.C. has a couple of items that look like
they might be done soon. Any estimates on when these will be
completed? Anything else not mentioned here?
2) Are there any currently opened JIRA entries that should be
considered showstoppers for this release? Any upgrade issues
definitely need to be sorted out and tested, maybe we should have a
JIRA for this. Documentation of new features should be finalized. I
think there may already be a JIRA entry for this.
3) Which bugs would be nice-to-have in this release but are not
showstoppers? I personally would like to see the patch for Derby-1
committed.
4) Are there any issues surrounding the client that should be
addressed before it is released? This deserves its own thread, and
there's already one started here:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/%3c42784236.70504@apache.org%3e
That thread got quiet, but I'll respond to that mail to keep the
discussion going.
5) Are there any changes to the packaging that people would like to
see for this release?
Feel free to add to this list and I'll keep track of all the responses.
andrew
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
Lance J. Andersen wrote:
> I have had a report internally where we have 2 unit tests fail with the
> DerbyNetwork client driver that did not fail with the DB2 type 4 driver
> with Derby.
>
> We have not had a chance to look into this yet in detail yet. If we
> can package up the failure, are there any volunteers on the IBM side who
> have access to the DB2 jdbc driver code to see why there might be a
> difference in behavior?
>
Please, just open a JIRA for the test failures so we can fix it in the
project.
--
Jeremy
Re: Planning for a 10.1 release
Posted by "Lance J. Andersen" <La...@Sun.COM>.
Daniel John Debrunner wrote:
>Lance J. Andersen wrote:
>
>
>>I have had a report internally where we have 2 unit tests fail with the
>>DerbyNetwork client driver that did not fail with the DB2 type 4 driver
>>with Derby.
>>
>>We have not had a chance to look into this yet in detail yet. If we
>>can package up the failure, are there any volunteers on the IBM side who
>>have access to the DB2 jdbc driver code to see why there might be a
>>difference in behavior?
>>
>>
>
>I think the issue should be addressed in terms of the Derby client only
>and not any IBM code.
>
>
I agree. I guess what i was trying to say is that I assume that the
bulk of the new client driver is a stripped down version of the IBM DB2
driver so that if you could run the test side by side using both drivers
and are able to compare the source, it might be easier to figure out
where the disconnect is based on the port of the code.
If that is not possible, there is always the old fashioned way ;-)
>Let's see what the issue is once you have a reproducible case.
>
>
I am waiting on this from the QA team as it is part of a pretty big
test harness. Once I have this, i will enter a jira.
>Dan.
>
>
>
>
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Lance J. Andersen wrote:
> I have had a report internally where we have 2 unit tests fail with the
> DerbyNetwork client driver that did not fail with the DB2 type 4 driver
> with Derby.
>
> We have not had a chance to look into this yet in detail yet. If we
> can package up the failure, are there any volunteers on the IBM side who
> have access to the DB2 jdbc driver code to see why there might be a
> difference in behavior?
I think the issue should be addressed in terms of the Derby client only
and not any IBM code.
Let's see what the issue is once you have a reproducible case.
Dan.
Re: Planning for a 10.1 release
Posted by "Lance J. Andersen" <La...@Sun.COM>.
I have had a report internally where we have 2 unit tests fail with the
DerbyNetwork client driver that did not fail with the DB2 type 4 driver
with Derby.
We have not had a chance to look into this yet in detail yet. If we
can package up the failure, are there any volunteers on the IBM side who
have access to the DB2 jdbc driver code to see why there might be a
difference in behavior?
For packaging, let us include the frameworks directory which has the
scripts for the networkserver (btw did you get a chance to commit the
patch i had sent to add the derbyclient support?)
Regards,
lance
Mamta Satoor wrote:
> Hi Andrew,
>
> I am working on getting JDBC updatable resultset functionality working
> for Network Server using Derby Net Client. Will send a patch in couple
> days if not earlier.
>
> Mamta
>
>
> On 5/17/05, Andrew McIntyre <mcintyre.a@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hello derby-dev,
>
> Now that there have been some significant new contributions to Derby
> since 10.0.2.1 <http://10.0.2.1> was released, I think we should
> begin planning for a
> 10.1 release. As promised earlier, I'll volunteer to be release
> manager. So, here goes:
>
> 1) Are there any new features or significant bugfixes near completion
> that should be in the 10.1 release? Dan mentioned that he would like
> to have his JSR-169 work included, Tomohito's fix for Derby-167 looks
> nearly complete, and David V.C. has a couple of items that look like
> they might be done soon. Any estimates on when these will be
> completed? Anything else not mentioned here?
>
> 2) Are there any currently opened JIRA entries that should be
> considered showstoppers for this release? Any upgrade issues
> definitely need to be sorted out and tested, maybe we should have a
> JIRA for this. Documentation of new features should be finalized. I
> think there may already be a JIRA entry for this.
>
> 3) Which bugs would be nice-to-have in this release but are not
> showstoppers? I personally would like to see the patch for Derby-1
> committed.
>
> 4) Are there any issues surrounding the client that should be
> addressed before it is released? This deserves its own thread, and
> there's already one started here:
>
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/%3c42784236.70504@apache.org%3e
> <http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/%3c42784236.70504@apache.org%3e>
>
> That thread got quiet, but I'll respond to that mail to keep the
> discussion going.
>
> 5) Are there any changes to the packaging that people would like to
> see for this release?
>
> Feel free to add to this list and I'll keep track of all the
> responses.
>
> andrew
>
>
Re: Planning for a 10.1 release
Posted by Mamta Satoor <ms...@gmail.com>.
Hi Andrew,
I am working on getting JDBC updatable resultset functionality working for
Network Server using Derby Net Client. Will send a patch in couple days if
not earlier.
Mamta
On 5/17/05, Andrew McIntyre <mc...@gmail.com> wrote:
>
> Hello derby-dev,
>
> Now that there have been some significant new contributions to Derby
> since 10.0.2.1 <http://10.0.2.1> was released, I think we should begin
> planning for a
> 10.1 release. As promised earlier, I'll volunteer to be release
> manager. So, here goes:
>
> 1) Are there any new features or significant bugfixes near completion
> that should be in the 10.1 release? Dan mentioned that he would like
> to have his JSR-169 work included, Tomohito's fix for Derby-167 looks
> nearly complete, and David V.C. has a couple of items that look like
> they might be done soon. Any estimates on when these will be
> completed? Anything else not mentioned here?
>
> 2) Are there any currently opened JIRA entries that should be
> considered showstoppers for this release? Any upgrade issues
> definitely need to be sorted out and tested, maybe we should have a
> JIRA for this. Documentation of new features should be finalized. I
> think there may already be a JIRA entry for this.
>
> 3) Which bugs would be nice-to-have in this release but are not
> showstoppers? I personally would like to see the patch for Derby-1
> committed.
>
> 4) Are there any issues surrounding the client that should be
> addressed before it is released? This deserves its own thread, and
> there's already one started here:
>
>
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/%3c42784236.70504@apache.org%3e
>
> That thread got quiet, but I'll respond to that mail to keep the
> discussion going.
>
> 5) Are there any changes to the packaging that people would like to
> see for this release?
>
> Feel free to add to this list and I'll keep track of all the responses.
>
> andrew
>
Re: Planning for a 10.1 release
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Hi Andrew,
I am working on adding synonym support to Derby. I hope to wrap that
work by this weekend.
Satheesh
>Many people are also assigned JIRA issues. So, if you currently have a
>JIRA issue assigned to you that you feel is a showstopper for a 10.1
>release, please speak up!
>
>andrew
>
>
>
>
>
Re: Planning for a 10.1 release
Posted by Sunitha Kambhampati <ks...@gmail.com>.
Andrew McIntyre wrote:
>
>Many people are also assigned JIRA issues. So, if you currently have a
>JIRA issue assigned to you that you feel is a showstopper for a 10.1
>release, please speak up!
>
>andrew
>
>
>
I plan to post a patch for Derby265 sometime tomorrow.
Thanks,
Sunitha.
Re: Planning for a 10.1 release
Posted by Army <qo...@sbcglobal.net>.
Andrew McIntyre wrote:
> If Army doesn't think his code is going to be production-quality in the
> timeframe of the release we're currently discussing, I think it should
> be left out, even if it were to be undocumented.
I should clarify. The reason I was thinking that this should not be documented
as "official" yet is because the work I've done is based on _working__drafts_ of
the SQL/XML syntax--which means we run the risk of the syntax changing in the
near future.
It's not that I'm doubting the "production quality" of what I've done--I think
what I've written is in good shape and I have spent time creating tests that are
thorough enough to make me believe my patch is Derby quality. There is, I
admit, one outstanding issue that I still need to investigate further, but
that's something I plan to look at after posting the intial patch, so that the
review process can carry on while I look at the issue (more on that one issue is
coming with the patch).
In re-reading my last email, I see that that wasn't clear--so I'm sorry for the
confusion. Yes, I think my patch (to be posted soon) is good enough quality to
be in the 10.1 release; my concern is simply in regard to documenting the XML
syntax one way and then changing it when the SQL/XML specs are formalized.
Army
Re: Planning for a 10.1 release
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I think one of the advantages of an open source product is the ability
to expose new functionality, with the understanding that it may change
in the future due to user feedback and changing standards. My hope
would be that we could use this kind of change to push a new standard if
appropriate, providing a working real world working example. As long as
it is properly documented I would rather see it included in the
distribution as a number of users of the product will never apply a
patch and build their own version.
I also would like to see more release early, release often. Along with
this I like incremental development where a large project is broken
down into smaller pieces which can be checked into the trunk along the
way. At each step existing functionality must not be broken, but it
may be the case that larger project does not work completely until
it is all checked in. A given release may only contain the groundwork
to get a larger project working, but that should not hold up the
release. I think it is better for everyone to share the working code
early.
My criteria for allowing a checkin to the trunk is if the added
functionality does not break existing functionality, and the added code
is progressing toward a change derby would eventually benefit from. To
that end adding an XML datatype seems like a excellent candidate. With
derby there aren't a lot of areas like
adding a datatype where other paths are not affected, but this is
one. We should appropriately document the "expermental" nature of this
particular feature warning that it's interfaces are not set yet. I am
ok with just documenting it, we could also implement properties that
must be set to use the feature.
Andrew McIntyre wrote:
> On May 24, 2005, at 6:29 PM, Army wrote:
>
> I should clarify. The reason I was thinking that this should not be
> documented as "official" yet is because the work I've done is based
> on _working__drafts_ of the SQL/XML syntax--which means we run the
> risk of the syntax changing in the near future.
>
>
> I see. Not so much incomplete or experimental as "preliminary". I think
> that's even the word used in your original post. Sorry for the confusion.
>
> On May 24, 2005, at 9:04 PM, Daniel John Debrunner wrote:
>
> I think it's more than just quality and in fact Army never says
> anything
> about "production quality".
>
>
> Indeed he didn't, but I was using Army's patch as an example to respond
> generally to the suggestion that something that is "experimental" be
> added to a release (thus, before it is "ready".)
>
> I think you said it best with:
>
> The release manager doesn't want to be endlessly delaying a release
> waiting for one
> or more contributors to submit or finish patches.
>
>
> +1
>
> Also, I plan on updating STATUS shortly with the collected feedback,
> it's more than a little out of date and could use some new info.
>
> andrew
>
Re: Planning for a 10.1 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On May 24, 2005, at 6:29 PM, Army wrote:
> I should clarify. The reason I was thinking that this should not be
> documented as "official" yet is because the work I've done is based on
> _working__drafts_ of the SQL/XML syntax--which means we run the risk
> of the syntax changing in the near future.
I see. Not so much incomplete or experimental as "preliminary". I think
that's even the word used in your original post. Sorry for the
confusion.
On May 24, 2005, at 9:04 PM, Daniel John Debrunner wrote:
> I think it's more than just quality and in fact Army never says
> anything
> about "production quality".
Indeed he didn't, but I was using Army's patch as an example to respond
generally to the suggestion that something that is "experimental" be
added to a release (thus, before it is "ready".)
I think you said it best with:
> The release manager doesn't want to be endlessly delaying a release
> waiting for one
> or more contributors to submit or finish patches.
+1
Also, I plan on updating STATUS shortly with the collected feedback,
it's more than a little out of date and could use some new info.
andrew
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Andrew McIntyre wrote:
> On 5/24/05, David Van Couvering <Da...@sun.com> wrote:
>
>>I think the XML functionality will be of great interest to users, and
>>they would like to play around with it.
>>
>>If there was a way we could document this as "experimental work" and
>>were explicit about its level of maturity, this would be reasonable.
>>I'm not sure what "support" means for an open source project...
>
>
> Maybe it's just me, but I feel that, even for an open source project,
> having an official release implies a certain level of code quality. If
> Army doesn't think his code is going to be production-quality in the
> timeframe of the release we're currently discussing, I think it should
> be left out, even if it were to be undocumented.
I think it's more than just quality and in fact Army never says anything
about "production quality".
Looking at this for any feature, the issues (in order) for any suggested
functionality are:
1) will a patch be ready in time for a release? Unless the
functionality is the driving force behind a release, then a release
should not be held up for a patch that doesn't exist yet. The release
manager doesn't want to be endlessly delaying a release waiting for one
or more contributors to submit or finish patches. Release early, release
*often* means that such a patch can soon be in another release.
2) is the API to the functionality correct? Is this api (either Java
classes, Jean Bean properties, SQL syntax, etc.) something that Derby
should keep stable for some number of releases?
This is probably the hardest issue to address, given that while Derby is
open source and thus no guarantees are made, in order to be widely used
the api's can not be changed every release. Though it may not be that
any api has to be present forever, the user community can provide input
to any api question, including removing an api. In some cases, like XML,
it seems it would make sense to provide some warnings on the
functionality indicating that they may change due to in-flux standards,
but discussion about such future changes would need to include the user
community. I don't want Derby to be in a position where it becomes hard
to release functionality until we get it 100% perfect.
3) Is the quality good enough? I would hope that code committed in the
trunk should be production quality, and this is enforced by
* functional tests
* code reviews
* eyes on the code
and the quality is further enhanced by getting the functionality into
user's hands, allowing them to test it. (release *early*, release often).
> And there are a couple of different ways for users to get access to
> this new feature for testing: anyone interested in early access can
> apply Army's patch to their view and try out the code once it is
> available, or as soon as the release is done, we can put up a snapshot
> of the latest trunk version that includes the XML support for users to
> try out.
Getting the functionality into a release will see wider use of it and
thus lead to higher quality, due to the feedback.
Other things to remember that we can always make subsequent 10.1
releases with bug fixes that improve the quality and that anyone can
make a 10.2 release anytime after Andrew makes a 10.1 release.
Dan.
Re: Planning for a 10.1 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On 5/24/05, David Van Couvering <Da...@sun.com> wrote:
> I think the XML functionality will be of great interest to users, and
> they would like to play around with it.
>
> If there was a way we could document this as "experimental work" and
> were explicit about its level of maturity, this would be reasonable.
> I'm not sure what "support" means for an open source project...
Maybe it's just me, but I feel that, even for an open source project,
having an official release implies a certain level of code quality. If
Army doesn't think his code is going to be production-quality in the
timeframe of the release we're currently discussing, I think it should
be left out, even if it were to be undocumented.
And there are a couple of different ways for users to get access to
this new feature for testing: anyone interested in early access can
apply Army's patch to their view and try out the code once it is
available, or as soon as the release is done, we can put up a snapshot
of the latest trunk version that includes the XML support for users to
try out.
andrew
Re: Planning for a 10.1 release
Posted by David Van Couvering <Da...@Sun.COM>.
I think the XML functionality will be of great interest to users, and
they would like to play around with it.
If there was a way we could document this as "experimental work" and
were explicit about its level of maturity, this would be reasonable.
I'm not sure what "support" means for an open source project...
David
Army wrote:
>Andrew McIntyre wrote:
>
>
>>- Scanning through the list, I noticed Army mentioned basic XML
>>support. Army, any estimate on when this might be contributed? Or is
>>this for a future release?
>>
>>
>
>I'm hoping to submit this support sometime later tonight or tomorrow. But that
>said, I do _NOT_ think we want to officially include XML support in this
>release. It's an entirely new feature that adds a good amount of code, and some
>of it is based on SQL/XML standards that aren't yet solidified (they're in
>working draft only).
>
>I imagine it will take some time to get a thorough review, and I also imagine
>that there are things I'll have to change in response to people's feedback. If
>your suggesting a release in the next two weeks, that seems too risky to me.
>
>I _do_ think it'd be good to get the support into the trunk codeline soon so
>that people can play with it and make comments--but I think it should remain
>undocumented and strictly unofficial until a later release. I.e. maybe it goes
>into the release jars, but we don't document the release as having official XML
>support...is that possible/desirable? If not, then I guess it'd be best to wait
>until after the release is cut before submitting to the trunk...
>
>Does that make sense?
>Army
>
>
>
Re: Planning for a 10.1 release
Posted by Army <qo...@sbcglobal.net>.
Andrew McIntyre wrote:
> - Scanning through the list, I noticed Army mentioned basic XML
> support. Army, any estimate on when this might be contributed? Or is
> this for a future release?
I'm hoping to submit this support sometime later tonight or tomorrow. But that
said, I do _NOT_ think we want to officially include XML support in this
release. It's an entirely new feature that adds a good amount of code, and some
of it is based on SQL/XML standards that aren't yet solidified (they're in
working draft only).
I imagine it will take some time to get a thorough review, and I also imagine
that there are things I'll have to change in response to people's feedback. If
your suggesting a release in the next two weeks, that seems too risky to me.
I _do_ think it'd be good to get the support into the trunk codeline soon so
that people can play with it and make comments--but I think it should remain
undocumented and strictly unofficial until a later release. I.e. maybe it goes
into the release jars, but we don't document the release as having official XML
support...is that possible/desirable? If not, then I guess it'd be best to wait
until after the release is cut before submitting to the trunk...
Does that make sense?
Army
Re: Planning for a 10.1 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Jeremy Boynes wrote:
>>
> If we rush a release out now and unify later, users see:
>
> 10.1 new ClientDataSource and EmbeddedSimpleDataSource
> 10.x new DerbyDataSource, deprecation of Client, EmbeddedSimple
> and Embedded
>
I am concerned about the packaging of the DerbyDataSource I think that
adding a jar file is very problematic in terms of
1) Ease of use. More and more more time spent on classpath issues.
How long did Tomohito spend on db2jcc_license.jar? How long
did you spend on oromatcher?
2) Problems with the jdbc driver not being in one jar file.
We've had reports of people having to manually combine
db2jcc_license.jar and db2jcc.jar to get the IBM
driver working in some instances.
3) Confusion about how the common jar file comes into play when
mixing client and server versions.
Maybe the DerbyDataSource could just be a nice wrapper around the
others. An add on jar file like the war file for the servlet, but not
necessary to core operation. So it becomes:
10.1 new ClientDataSource and EmbeddedSimpleDataSource
10.x new DerbyDataSource, in additon to Client, EmbeddedSimple
and Embedded
That way we can forge ahead with both the release and a unified
datasource and perhaps better packaging options will become apparent for
future releases.
Kathey
Re: Planning for a 10.1 release
Posted by David Van Couvering <da...@vancouvering.com>.
I concur with this approach: a lot of trains leaving the station, and if
you miss a train you just get on the next train.
David
Daniel John Debrunner wrote:
>
> Some of my discussion on this has also been looking at the bigger
> picture, how long should a release manager wait for a patch for a
> release if it is not a showstopper. E.g. if a contributor says they will
> take two months to complete a feature, then I would say it's better
> value to the community to get a release out now, rather than wait two
> months. If the estimate was a few days but the patch didn't appear for a
> few weeks, I would again say any release shouldn't wait for a single
> non-show stopper item. Release early, release often means the next
> release can include such a feature.
>
> Dan.
>
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jeremy Boynes wrote:
> Daniel John Debrunner wrote:
>> This approach is a great
>> chance for the open source Darwin approach, see what the users like,
>> see how much confusion (e.g. questions in derby-user) there is with a
>> single data source with all properties vs. multiple data sources with
>> specific properties.
>>
>
> Should I roll it into the main tree then? Then we can have both there in
> the alpha/beta versions and get can feedback from users early.
That sounds good, I was under the impression that it wasn't anywhere
near ready. I would caution against just committing it yourself directly
into the trunk, but post as a patch so that it can be voted on. This
seems to fall into the 'Doubtful changes, new features ...' paragraph of
the changes section in
http://db.apache.org/source.html
Some of my discussion on this has also been looking at the bigger
picture, how long should a release manager wait for a patch for a
release if it is not a showstopper. E.g. if a contributor says they will
take two months to complete a feature, then I would say it's better
value to the community to get a release out now, rather than wait two
months. If the estimate was a few days but the patch didn't appear for a
few weeks, I would again say any release shouldn't wait for a single
non-show stopper item. Release early, release often means the next
release can include such a feature.
Dan.
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
Daniel John Debrunner wrote:
> Jeremy Boynes wrote:
>
>
>>If we rush a release out now and unify later, users see:
>>
>>10.1 new ClientDataSource and EmbeddedSimpleDataSource
>>10.x new DerbyDataSource, deprecation of Client, EmbeddedSimple
>> and Embedded
>>
>>If x = 1.1 or 2 then what we did in 10.1 looks silly and, because it is
>>a public API, we live with it forever (or a couple of years at least).
>
>
> I don't see it as silly, but the unified datasource being an feature
> that might obsolete the other data sources.
If the others existed already then fine - but they are new this release
so its a feature being obsoleted almost immediately.
> This approach is a great
> chance for the open source Darwin approach, see what the users like,
> see how much confusion (e.g. questions in derby-user) there is with a
> single data source with all properties vs. multiple data sources with
> specific properties.
>
Should I roll it into the main tree then? Then we can have both there in
the alpha/beta versions and get can feedback from users early.
--
Jeremy
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jeremy Boynes wrote:
>>
> If we rush a release out now and unify later, users see:
>
> 10.1 new ClientDataSource and EmbeddedSimpleDataSource
> 10.x new DerbyDataSource, deprecation of Client, EmbeddedSimple
> and Embedded
>
> If x = 1.1 or 2 then what we did in 10.1 looks silly and, because it is
> a public API, we live with it forever (or a couple of years at least).
I don't see it as silly, but the unified datasource being an feature
that might obsolete the other data sources. This approach is a great
chance for the open source Darwin approach, see what the users like,
see how much confusion (e.g. questions in derby-user) there is with a
single data source with all properties vs. multiple data sources with
specific properties.
I'm really think it would be the best to get the derby client into a
release so that people can use it and thus report bugs against it. I'm
concerned that if we wait until it is perfect we will never make a
release. It seems that we are doing a poor job at "release early release
often".
If we are trading "supporting" a standard api (current DataSource's) for
a couple of years against wider use of the derby client sooner (leading
to higher quality etc.) then to me the wider use sooner provides the
greater benefit (and the "supporting" for a couple of years is almost
zero cost).
Dan.
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
Daniel John Debrunner wrote:
> Jeremy Boynes wrote:
>
>>Andrew McIntyre wrote:
>>
>>
>>>I'm thinking that in the interests of getting an official release out
>>>with the Derby client, I'd like to aim for a release in about two
>>>weeks or so.
>>>
>>
>>When we're ready - not before :-)
>
>
> I think we are ready, it would be good for Derby to get the open source
> client out as part of a release, release early release often!
>
>
I disagree. In this area alone:
* we have not made a decision on unification
* we voted to have the client driver match the embedded but
functional differences remain
Early is one thing, premature is another.
>>>- Jeremy, in what timeframe do you think you will have a working
>>>prototype for the Datasource API changes? If you need help running
>>>tests against the prototype, please email me, I can help out with
>>>that. But, it's not clear to me that this is something that must be in
>>>the 10.1 release. Is this something that could be deferred to a 10.2
>>>(or even a 10.1.x) release? It's not unusual to manage API changes at
>>>release boundaries, so I don't think that having to support the
>>>current Datasource API going into the future is necessarily a reason
>>>to hold up this release.
>
>
> Also I don't think any decision has been made on if a unified data
> source api does make Derby easier to use.
>
> I'm still looking for a table of properties and how they apply to
> embedded or server mode. I think you keep pointing me to the prototype
> but your initial e-mail said it was missing some of the properties and
> the code I just looked at didn't seem to have all the client side
> properties.
>
The ones that are missing are:
* those related to trace
* resultSetHoldability
* retrieveMessageText
* securityMechanism
From the user's perspective, all of these /should/ operate the same on
both client and embedded and so I would contend are not distinguishing
factors in this decision. We can either leave these undocumented for the
current client or implement them in embedded in the future.
> The discussion is about having changing the api from
>
> ------------------------------------------------------------------------
> EmbeddedDataSource + embedded specific properties
> EmbeddedSimpleDataSource + embedded specific properties [needed for JSR 169]
> ClientDataSource + client specific properties
> ------------------------------------------------------------------------
>
> TO
>
> ------------------------------------------------------------------------
> UnifiedDataSource + complete set of embedded & client properties
> EmbeddedDataSource + embedded specific properties [possibly deprecated
> at some point]
> ------------------------------------------------------------------------
>
> While the UnifiedDataSource looks great when presented like that, the
> details are in the list of properties supported by the unified data
> source, and does the combined list end up being simpler or more
> confusing. I can see in the future more properties being added to
> support client side encryption, alternate transport, SSL client
> certificates, all ones that make no sense for embedded.
>
I think they do, specifically where we are embedded in a multi-user
environment like an appserver. For example, a client side certificate,
whilst applicable to SSL, could also be used in embedded authentication.
The difference is between traditional embedded mode where there was an
implicit trust between application and database code, and multi-user
scenarios where trust needs to be established for each connection or
operation.
> Then beyond the api, there are possible technical issues with the client
> and embedded engine sharing code and ensuring that works in the future
> for different versions of client and embedded.
>
Those issues apply regardless of whether we unify or not. Unless we put
client and embedded on different release cycles (which seems odd) they
will be tested together, part of which will be need to be
interoperability with older versions.
>
>
>>I still think introducing a major new API in this release with the
>>potential of it then changing incompatibly in the next one (especially
>>a dot release) is confusing.
>
>
> I think that's a little strong. The basic concept of the api is standard
> and the same in both cases, a class name and a set of Java Bean
> (DataSource) properties. And if 10.1 was released in its current form,
> three data sources, then it would not be changed incompatibly in the
> next release. A subsequent release that included a unified data source
> would be adding that option to Derby, with possible deprecation of other
> datasources in the future.
>
If we rush a release out now and unify later, users see:
10.1 new ClientDataSource and EmbeddedSimpleDataSource
10.x new DerbyDataSource, deprecation of Client, EmbeddedSimple
and Embedded
If x = 1.1 or 2 then what we did in 10.1 looks silly and, because it is
a public API, we live with it forever (or a couple of years at least).
--
Jeremy
Re: Planning for a 10.1 release
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
From: "David Jencks" <dj...@gluecode.com>
> If it works, no problem. If the db tracked which xids had been used
> and complained if you tried to reuse one, I think you would need to
> change your tests. If you are creating a new db for each test (I
> didn't look) then also no problem :-)
It does work ... even for the same database. I suppose that it must because
the specs do not say that the Xid has to be a unique id in time.
Regards
Re: Planning for a 10.1 release
Posted by David Jencks <dj...@gluecode.com>.
On May 26, 2005, at 4:16 AM, Dibyendu Majumdar wrote:
> From: "David Jencks" <dj...@apache.org>
>> ps. I would be sure you never use the same xid twice. I think it
>> would
>> be entirely appropriate for derby to object if you do. I didn't see
>> the implementation in the Utils class so I'm not sure if your xids are
>> unique or not.
>
> I do use the same Xid in my tests. So far no problem. In any case, as
> long
> as the Xid is not currently active, would it matter?
>
If it works, no problem. If the db tracked which xids had been used
and complained if you tried to reuse one, I think you would need to
change your tests. If you are creating a new db for each test (I
didn't look) then also no problem :-)
thanks
david jencks
Re: Planning for a 10.1 release
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
From: "David Jencks" <dj...@apache.org>
> ps. I would be sure you never use the same xid twice. I think it would
> be entirely appropriate for derby to object if you do. I didn't see
> the implementation in the Utils class so I'm not sure if your xids are
> unique or not.
I do use the same Xid in my tests. So far no problem. In any case, as long
as the Xid is not currently active, would it matter?
Regards
Re: Planning for a 10.1 release
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
David,
All the tests (except the join test ) pass with both Oracle and Derby
Embedded driver.
Regards
----- Original Message -----
From: "David Jencks" <dj...@apache.org>
To: "Derby Development" <de...@db.apache.org>
Sent: Thursday, May 26, 2005 6:09 AM
Subject: Re: Planning for a 10.1 release
> I took a quick look at Dibyendu's tests and I think they are OK. I
> would like to know if these tests pass with the embedded xa support.
> Tests 8 and 9 are IMO completely spec compliant but I believe they will
> not pass with the majority of databases claiming xa support. As such
> it might not be wise to insist on them :-)
>
> One comment I have is that the app servers I have worked with (geronimo
> and jboss) will use this sequence of calls:
>
> xar.start(xid, TM_NOFLAGS);
> xar.end(xid, TM_SUSPEND);
> xar.end(xid, TM_SUCCESS);
> xar.prepare/commit
>
> You might want to add strategically located suspend calls to make sure
> that makes no difference.
>
> As far as connection handles and pooling, the usage in the tests is
> absolutely standard and I'm sure it is what websphere uses also.
>
> Typically with an ejb CMT call, we have the following sequence of
> events:
>
> 1. container starts tx
> 2. ejb obtains a connection handle. This involves enlisting the
> XAResource associated with the managed connection/XAConnection with the
> current tx. and obtaining a handle from the mc. We can't tell which
> order this occurs in, but it doesn't seem to make a difference in this
> test.
> 3. ejb uses cx handle
> 4. ejb closes cx handle. There is no way for the connection manager to
> detect this is going to happen...
> 5 mc/XAConnection notifies listeners that the handle was closed. At
> this time the connection manager could delist/end the XAResource from
> the transaction.
>
> Note the order of steps 4 and 5, which is the same as in Dibyendu's
> tests.
>
> According to my interpretation of the xa spec, it should now be safe
> (no open cx handles and no tx associated with mc) to put the mc back in
> the pool. However, I believe most "xa" drivers don't let you do this
> but require you to commit the tx first before starting another.
>
> In conclusion, I would recommend experimenting with the end(TM_SUSPEND)
> call, but I think at least tests 1-7 should pass before releasing the
> driver.
>
> Many thanks,
> david jencks
>
> ps. I would be sure you never use the same xid twice. I think it would
> be entirely appropriate for derby to object if you do. I didn't see
> the implementation in the Utils class so I'm not sure if your xids are
> unique or not.
>
>
> On May 25, 2005, at 7:34 PM, Jeremy Boynes wrote:
>
> > David's the Geronimo guru on XA.
> >
> > My understanding is that it is legal for a coordinator to delist a
> > resource before the end of a transaction and return it to the pool; it
> > could then be used by another thread (potentially in another
> > transaction) or just closed.
> >
> > However, there are many resource managers out there that do not
> > support this so most app servers (OK, at least Geronimo and from what
> > you say WebSphere) have a mechanism for associating the physical
> > connection with the transaction until it is over.
> >
> > I haven't looked at the bug but we should clearly document how Derby
> > behaves, especially if client and embedded behaviour are different.
> >
> > --
> > Jeremy
> >
> > Kathey Marsden wrote:
> >> Dibyendu Majumdar wrote:
> >>> From: "Kathey Marsden" <km...@sbcglobal.net>
> >>>
> >>>
> >>>> I think the workaround for DERBY-246, to leave the logical
> >>>> connection
> >>>> open until the end of the global transaction, should be documented
> >>>> in
> >>>> the release notes.
> >>>>
> >>>
> >>> Hi Kathey,
> >>>
> >>> Unfortunately, this is not a workaround. For example, see section
> >>> 4.2 of JTA
> >>> spec which describes how an application server would use logical
> >>> connections.
> >>>
> >>>
> >> Firstly I want to say that I am motivated to get this fixed. I just
> >> don't think I can get it fixed in the time frame for the 10.1
> >> release. I don't think it should stop the release. The example says:
> >> "The figure that follows illustrates the usage of
> >> JTA. The steps shown are for illustrative purposes, they are not
> >> prescriptive:"
> >> In this example, with our workaround, I think steps 11 and 12 would
> >> move
> >> down to the end.
> >> I talked with the folks that use XA at Websphere. They said.
> >> "in WAS, we don't close the connections until after they are no longer
> >> in transactions (closing, means put them in the pool to be used by
> >> others)"
> >> So it seems like it is a workaround. Could you offer a scenario
> >> where
> >> it is not a reasonable workaround
> >> Perhaps Jeremy has some perspective as well as to the XA impact.
> >> Jeremy?
> >> Thanks
> >> Kathey
> >
>
Re: Planning for a 10.1 release
Posted by David Jencks <dj...@apache.org>.
I took a quick look at Dibyendu's tests and I think they are OK. I
would like to know if these tests pass with the embedded xa support.
Tests 8 and 9 are IMO completely spec compliant but I believe they will
not pass with the majority of databases claiming xa support. As such
it might not be wise to insist on them :-)
One comment I have is that the app servers I have worked with (geronimo
and jboss) will use this sequence of calls:
xar.start(xid, TM_NOFLAGS);
xar.end(xid, TM_SUSPEND);
xar.end(xid, TM_SUCCESS);
xar.prepare/commit
You might want to add strategically located suspend calls to make sure
that makes no difference.
As far as connection handles and pooling, the usage in the tests is
absolutely standard and I'm sure it is what websphere uses also.
Typically with an ejb CMT call, we have the following sequence of
events:
1. container starts tx
2. ejb obtains a connection handle. This involves enlisting the
XAResource associated with the managed connection/XAConnection with the
current tx. and obtaining a handle from the mc. We can't tell which
order this occurs in, but it doesn't seem to make a difference in this
test.
3. ejb uses cx handle
4. ejb closes cx handle. There is no way for the connection manager to
detect this is going to happen...
5 mc/XAConnection notifies listeners that the handle was closed. At
this time the connection manager could delist/end the XAResource from
the transaction.
Note the order of steps 4 and 5, which is the same as in Dibyendu's
tests.
According to my interpretation of the xa spec, it should now be safe
(no open cx handles and no tx associated with mc) to put the mc back in
the pool. However, I believe most "xa" drivers don't let you do this
but require you to commit the tx first before starting another.
In conclusion, I would recommend experimenting with the end(TM_SUSPEND)
call, but I think at least tests 1-7 should pass before releasing the
driver.
Many thanks,
david jencks
ps. I would be sure you never use the same xid twice. I think it would
be entirely appropriate for derby to object if you do. I didn't see
the implementation in the Utils class so I'm not sure if your xids are
unique or not.
On May 25, 2005, at 7:34 PM, Jeremy Boynes wrote:
> David's the Geronimo guru on XA.
>
> My understanding is that it is legal for a coordinator to delist a
> resource before the end of a transaction and return it to the pool; it
> could then be used by another thread (potentially in another
> transaction) or just closed.
>
> However, there are many resource managers out there that do not
> support this so most app servers (OK, at least Geronimo and from what
> you say WebSphere) have a mechanism for associating the physical
> connection with the transaction until it is over.
>
> I haven't looked at the bug but we should clearly document how Derby
> behaves, especially if client and embedded behaviour are different.
>
> --
> Jeremy
>
> Kathey Marsden wrote:
>> Dibyendu Majumdar wrote:
>>> From: "Kathey Marsden" <km...@sbcglobal.net>
>>>
>>>
>>>> I think the workaround for DERBY-246, to leave the logical
>>>> connection
>>>> open until the end of the global transaction, should be documented
>>>> in
>>>> the release notes.
>>>>
>>>
>>> Hi Kathey,
>>>
>>> Unfortunately, this is not a workaround. For example, see section
>>> 4.2 of JTA
>>> spec which describes how an application server would use logical
>>> connections.
>>>
>>>
>> Firstly I want to say that I am motivated to get this fixed. I just
>> don't think I can get it fixed in the time frame for the 10.1
>> release. I don't think it should stop the release. The example says:
>> "The figure that follows illustrates the usage of
>> JTA. The steps shown are for illustrative purposes, they are not
>> prescriptive:"
>> In this example, with our workaround, I think steps 11 and 12 would
>> move
>> down to the end.
>> I talked with the folks that use XA at Websphere. They said.
>> "in WAS, we don't close the connections until after they are no longer
>> in transactions (closing, means put them in the pool to be used by
>> others)"
>> So it seems like it is a workaround. Could you offer a scenario
>> where
>> it is not a reasonable workaround
>> Perhaps Jeremy has some perspective as well as to the XA impact.
>> Jeremy?
>> Thanks
>> Kathey
>
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
David's the Geronimo guru on XA.
My understanding is that it is legal for a coordinator to delist a
resource before the end of a transaction and return it to the pool; it
could then be used by another thread (potentially in another
transaction) or just closed.
However, there are many resource managers out there that do not support
this so most app servers (OK, at least Geronimo and from what you say
WebSphere) have a mechanism for associating the physical connection with
the transaction until it is over.
I haven't looked at the bug but we should clearly document how Derby
behaves, especially if client and embedded behaviour are different.
--
Jeremy
Kathey Marsden wrote:
> Dibyendu Majumdar wrote:
>
>
>>From: "Kathey Marsden" <km...@sbcglobal.net>
>>
>>
>>
>>>I think the workaround for DERBY-246, to leave the logical connection
>>>open until the end of the global transaction, should be documented in
>>>the release notes.
>>>
>>>
>>
>>Hi Kathey,
>>
>>Unfortunately, this is not a workaround. For example, see section 4.2 of JTA
>>spec which describes how an application server would use logical
>>connections.
>>
>>
>>
>
>
> Firstly I want to say that I am motivated to get this fixed. I just
> don't think I can get it fixed in the time frame for the 10.1 release.
> I don't think it should stop the release.
>
> The example says:
> "The figure that follows illustrates the usage of
> JTA. The steps shown are for illustrative purposes, they are not
> prescriptive:"
> In this example, with our workaround, I think steps 11 and 12 would move
> down to the end.
>
> I talked with the folks that use XA at Websphere. They said.
> "in WAS, we don't close the connections until after they are no longer
> in transactions (closing, means put them in the pool to be used by others)"
>
> So it seems like it is a workaround. Could you offer a scenario where
> it is not a reasonable workaround
> Perhaps Jeremy has some perspective as well as to the XA impact. Jeremy?
>
> Thanks
>
> Kathey
>
>
Re: Planning for a 10.1 release
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
From: "Kathey Marsden" <km...@sbcglobal.net>
> Firstly I want to say that I am motivated to get this fixed. I just
> don't think I can get it fixed in the time frame for the 10.1 release.
> I don't think it should stop the release.
Kathey,
I have no problem with releasing the client as it will be useful even
without XA support. My only objection is to say that XA is working because
it is not. As long as the release notes make that clear, fine.
>
> The example says:
> "The figure that follows illustrates the usage of
> JTA. The steps shown are for illustrative purposes, they are not
> prescriptive:"
> In this example, with our workaround, I think steps 11 and 12 would move
> down to the end.
>
> I talked with the folks that use XA at Websphere. They said.
> "in WAS, we don't close the connections until after they are no longer
> in transactions (closing, means put them in the pool to be used by
others)"
>
There are several problems with this. We cannot assume that what WAS does is
the correct thing to do. Obviously WAS knows about limitations/problems in
DB2 drivers and works around them. But to expect everyone else to put in
workarounds is unreasonable.
Secondly, are the WAS folks saying that they do not close the logical
connection ? The physical connection should not be closed, and should be
reused, but the logical connection is typically closed. This is because, the
logical connection may not be under control of the application server. For
example, what if the application has opened a connection - it will close it
once it no longer needs the connection. Of coures, this can be worked around
by providing another layer of abstraction - ie - wrap the logical connection
in a proxy that suppresses the close - but that seems to me to defeat the
whole objective of having logical connections.
> So it seems like it is a workaround. Could you offer a scenario where
> it is not a reasonable workaround
Certainly for me this is not a work around. The way I have implemented JTA
is as follows:
Application requests a connection
SimpleJTA acquires a physical connection from the pool, creating one if
necessary.
It then creates the logical connection.
The resource is enlisted with the global transaction.
The logical connection is returned to the application.
Application closes the logical connection.
This results in a call to connectionClosed event.
SimpleJTA traps this, and notes that the application is not using the
connection. However, it does not delist the XA resource yet, because it
assumes that the application may want the connection again. Therefore, it
stores the connection in a cache keyed by Xid.
Now, assume that the application wants another connection for the same
global transaction.
In this case, SimpleJTA will return the connection that is already enlisted.
When the application calls commit() or rollback(), SimpleJTA finally delists
all the resources by calling end() and then completes the transaction.
Therefore, in SimpleJTA, a physical connection is reserved for use by a
transaction until the transaction is completed. I did this as an
optimisation, because in modern DAO implementations, a connection may be
acquired and released several times in quick succession within the same
global transaction. It seemed a waste to delist and enlist the resource
everytime this happens.
Theoretically, a physical connection can be resused by any other transaction
after end() is called. SimpleJTA supports this as an option - but in my
testing I found that Oracle does not like this, specially if different
threads are involved. Oracle is okay with the same thread reusing a
connection for another transaction after end(), but not if another thread
attempts to do so.
The point is that this is definitely a bug. I do not think that the
workaround is reasonable.
I am also concerned that there may be other bugs as yet undiscovered.
Regards
Dibyendu
Re: Planning for a 10.1 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dibyendu Majumdar wrote:
>From: "Kathey Marsden" <km...@sbcglobal.net>
>
>
>>I think the workaround for DERBY-246, to leave the logical connection
>>open until the end of the global transaction, should be documented in
>>the release notes.
>>
>>
>
>Hi Kathey,
>
>Unfortunately, this is not a workaround. For example, see section 4.2 of JTA
>spec which describes how an application server would use logical
>connections.
>
>
>
Firstly I want to say that I am motivated to get this fixed. I just
don't think I can get it fixed in the time frame for the 10.1 release.
I don't think it should stop the release.
The example says:
"The figure that follows illustrates the usage of
JTA. The steps shown are for illustrative purposes, they are not
prescriptive:"
In this example, with our workaround, I think steps 11 and 12 would move
down to the end.
I talked with the folks that use XA at Websphere. They said.
"in WAS, we don't close the connections until after they are no longer
in transactions (closing, means put them in the pool to be used by others)"
So it seems like it is a workaround. Could you offer a scenario where
it is not a reasonable workaround
Perhaps Jeremy has some perspective as well as to the XA impact. Jeremy?
Thanks
Kathey
Re: Planning for a 10.1 release
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
From: "Kathey Marsden" <km...@sbcglobal.net>
> I think the workaround for DERBY-246, to leave the logical connection
> open until the end of the global transaction, should be documented in
> the release notes.
Hi Kathey,
Unfortunately, this is not a workaround. For example, see section 4.2 of JTA
spec which describes how an application server would use logical
connections.
Also, do we know if this is the only problem? I am worried that the DB2 type
4 drivers do not support XA, and if you have ported the DB2 driver, then
very likely this won't support XA either.
Regards
Re: Planning for a 10.1 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dibyendu Majumdar wrote:
>The opensource client does not support XA correctly as yet. If this is
>released then it should be made clear in the documentation that the XA
>support is not functional. The other alternative is to wait for it to be
>fixed.
>
>
>
I think the workaround for DERBY-246, to leave the logical connection
open until the end of the global transaction, should be documented in
the release notes.
Re: Planning for a 10.1 release
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
From: "Daniel John Debrunner" <dj...@debrunners.com>
> I think we are ready, it would be good for Derby to get the open source
> client out as part of a release, release early release often!
The opensource client does not support XA correctly as yet. If this is
released then it should be made clear in the documentation that the XA
support is not functional. The other alternative is to wait for it to be
fixed.
Regards
Dibyendu
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jeremy Boynes wrote:
> Andrew McIntyre wrote:
>
>>
>> I'm thinking that in the interests of getting an official release out
>> with the Derby client, I'd like to aim for a release in about two
>> weeks or so.
>>
>
> When we're ready - not before :-)
I think we are ready, it would be good for Derby to get the open source
client out as part of a release, release early release often!
>> - Jeremy, in what timeframe do you think you will have a working
>> prototype for the Datasource API changes? If you need help running
>> tests against the prototype, please email me, I can help out with
>> that. But, it's not clear to me that this is something that must be in
>> the 10.1 release. Is this something that could be deferred to a 10.2
>> (or even a 10.1.x) release? It's not unusual to manage API changes at
>> release boundaries, so I don't think that having to support the
>> current Datasource API going into the future is necessarily a reason
>> to hold up this release.
Also I don't think any decision has been made on if a unified data
source api does make Derby easier to use.
I'm still looking for a table of properties and how they apply to
embedded or server mode. I think you keep pointing me to the prototype
but your initial e-mail said it was missing some of the properties and
the code I just looked at didn't seem to have all the client side
properties.
The discussion is about having changing the api from
------------------------------------------------------------------------
EmbeddedDataSource + embedded specific properties
EmbeddedSimpleDataSource + embedded specific properties [needed for JSR 169]
ClientDataSource + client specific properties
------------------------------------------------------------------------
TO
------------------------------------------------------------------------
UnifiedDataSource + complete set of embedded & client properties
EmbeddedDataSource + embedded specific properties [possibly deprecated
at some point]
------------------------------------------------------------------------
While the UnifiedDataSource looks great when presented like that, the
details are in the list of properties supported by the unified data
source, and does the combined list end up being simpler or more
confusing. I can see in the future more properties being added to
support client side encryption, alternate transport, SSL client
certificates, all ones that make no sense for embedded.
Then beyond the api, there are possible technical issues with the client
and embedded engine sharing code and ensuring that works in the future
for different versions of client and embedded.
> I still think introducing a major new API in this release with the
> potential of it then changing incompatibly in the next one (especially
> a dot release) is confusing.
I think that's a little strong. The basic concept of the api is standard
and the same in both cases, a class name and a set of Java Bean
(DataSource) properties. And if 10.1 was released in its current form,
three data sources, then it would not be changed incompatibly in the
next release. A subsequent release that included a unified data source
would be adding that option to Derby, with possible deprecation of other
datasources in the future.
Dan.
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
Andrew McIntyre wrote:
>
> I'm thinking that in the interests of getting an official release out
> with the Derby client, I'd like to aim for a release in about two
> weeks or so.
>
When we're ready - not before :-)
>
> - Jeremy, in what timeframe do you think you will have a working
> prototype for the Datasource API changes? If you need help running
> tests against the prototype, please email me, I can help out with
> that. But, it's not clear to me that this is something that must be in
> the 10.1 release. Is this something that could be deferred to a 10.2
> (or even a 10.1.x) release? It's not unusual to manage API changes at
> release boundaries, so I don't think that having to support the
> current Datasource API going into the future is necessarily a reason
> to hold up this release.
>
There is a "working" prototype in the datasource branch - by some
definition of "working" anyway :-) It can connect to the server both
client and embedded and supports several of the Derby specific properties.
Implementation is here:
http://svn.apache.org/viewcvs.cgi/incubator/derby/code/branches/datasource/src/java/org/apache/derby/api/BasicDataSource.java?view=markup
http://svn.apache.org/viewcvs.cgi/incubator/derby/code/branches/datasource/src/java/org/apache/derby/api/DerbyDataSource.java?view=markup
There are unit tests as part of this module that test the connect
behavior. It uses the existing implementations underneath so I would
anticipate major problems. I could use help branching the client test
framework so that it uses this instead.
Part of this issue is the alignment of behaviour of the client and
embedded drivers (e.g. trace) - the vote was in favour of doing this and
this prototype is one option for doing that; I have not seen any other
changes so far. It would be good to make a decision on whether we are
going to unify the drivers before I add more to the prototype or someone
else starts changing the existing implementations.
I still think introducing a major new API in this release with the
potential of it then changing incompatibly in the next one (especially a
dot release) is confusing.
--
Jeremy
Re: Planning for a 10.1 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Andrew McIntyre wrote:
>Many people are also assigned JIRA issues. So, if you currently have a
>JIRA issue assigned to you that you feel is a showstopper for a 10.1
>release, please speak up!
>
>andrew
>
>
>
I plan to fix DERBY-255 and DERBY-213 this week. Also DERBY-246 needs a release note for the workaround.
Thanks
Kathey
Re: restarting work on documenting the btree module ...
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I think we agree. I will wait for your sample.
Dibyendu Majumdar wrote:
> Mike,
>
> Don't know if my previous comment was clear enough.
> I think that rather than putting the description of each Java file in the
> package.html, we can update the Javadoc comments within each Java file. The
> end result will be the same - you will get a package description, and class
> summary for each of the Java files.
>
> The easiest way probably would be for me to make the changes and send you a
> sample. I will do this by tomorrow.
>
> Regards
>
> Dibyendu
>
>
>
Re: restarting work on documenting the btree module ...
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
Mike,
Don't know if my previous comment was clear enough.
I think that rather than putting the description of each Java file in the
package.html, we can update the Javadoc comments within each Java file. The
end result will be the same - you will get a package description, and class
summary for each of the Java files.
The easiest way probably would be for me to make the changes and send you a
sample. I will do this by tomorrow.
Regards
Dibyendu
Re: restarting work on documenting the btree module ...
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I applied the patch with minor changes, check to make sure it all
worked. I had some problems applying the patch (got patch to
crash), I think it had to do with line ending in the patch file.
I will look at btree directory next. If you have any other fixes
send them along, and if you see some documentation lacking feel
free to ask for some more. Historically in the store code most
of the javadoc work was put into making the iapi side complete
and acurate - so you may be the first looking at some of the impl
side javadoc. I am sure some is out of date.
I much rather have the result of this documentation effort be as
much as possible reflected in the javadoc present in the code.
Dibyendu Majumdar wrote:
> Please see attached patch.
Re: restarting work on documenting the btree module ...
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
Please see attached patch.
Re: restarting work on documenting the btree module ...
Posted by Andrew McIntyre <mc...@gmail.com>.
On Jun 7, 2005, at 4:11 PM, Dibyendu Majumdar wrote:
> Yes, the URL is:
> http://incubator.apache.org/derby/javadoc/engine/
> This is under the Papers tab, but for some reason only appears in
> the menu
> to the left,
> under Derby Engine.
Just a note that due to an authentication problem on my end, the
javadoc on the website hasn't sync'd up in a little while. I just
sync'd a fresh copy, so it should be viewable within 4 hours. The
javadoc and manuals should sync up on a regular schedule again
beginning this evening.
andrew
Re: restarting work on documenting the btree module ...
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Dibyendu Majumdar wrote:
>
> Yes, the URL is:
> http://incubator.apache.org/derby/javadoc/engine/
> This is under the Papers tab, but for some reason only appears in the menu
> to the left,
> under Derby Engine.
I'm catching this threads in bursts, so might be missing many points
(feel free to nag me) ...
The Papers tab at http://incubator.apache.org/derby/papers has a link to
http://incubator.apache.org/derby/javadoc/engine/ on the left-hand nav
menu -- and only there. That's an oversight. I'll also add the link to
the body of the http://incubator.apache.org/derby/papers/index.html page.
-jean
Re: restarting work on documenting the btree module ...
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
From: "Mike Matrigali" <mi...@sbcglobal.net>
> I just looked at the one dan referred to and I think my approach
> is wrong, at least if using javadoc to provide this information.
> What is appropriate in the package.html is an overview of what the
> package does - but I think the per file information should just
> be what javadoc provides and I should just make sure the javadoc
> in the individual files works.
This is what I suggested.
> Let me see if I can get current javadoc to give what I think it
> should and you let me know if it looks right. Likely to check
> in very limited html package.html with just overview of package -
> you can format as you see fit.
Hold on, I am sending you a package.html in a few minutes.
> I thought that the apache site was going to have a built set of
> the source code javadoc, at least from releases if not from
> nightly builds but I could not find it. Does it exist?
Yes, the URL is:
http://incubator.apache.org/derby/javadoc/engine/
This is under the Papers tab, but for some reason only appears in the menu
to the left,
under Derby Engine.
Regards
Dibyendu
Re: restarting work on documenting the btree module ...
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I thought I remembered dan doing something like this, but could
not remember the name. That is why I sent the preliminary out
before checking it in.
I just looked at the one dan referred to and I think my approach
is wrong, at least if using javadoc to provide this information.
What is appropriate in the package.html is an overview of what the
package does - but I think the per file information should just
be what javadoc provides and I should just make sure the javadoc
in the individual files works.
Let me see if I can get current javadoc to give what I think it
should and you let me know if it looks right. Likely to check
in very limited html package.html with just overview of package -
you can format as you see fit.
I thought that the apache site was going to have a built set of
the source code javadoc, at least from releases if not from
nightly builds but I could not find it. Does it exist?
Dibyendu Majumdar wrote:
> From: "Mike Matrigali" <mi...@sbcglobal.net>
>
>>First here is a start at info about files in the index directory.
>>Is this a good start. I would actually like to check this information
>>into the source code, and am looking for some opinions about how best
>>to do it. Currently it is just text, but ideally I would like to hook
>>it up to html and the javadoc system some how.
>
>
> Hi Mike. I guess the correct way would be create a package.html file and
> check this in. I can do the conversion from your text.
>
>
>>Below is a quick description of what the files do, see javadoc in the
>>individual files for more explanation of each.
>
>
> I would suggest that we update the documentation in each of Java files so
> that all this becomes part of the Javadoc. I'd like to correct the existing
> Javadoc comments and also add new new comments. Alternatively, if you add
> the comments yourself, I can fix the html tags so that the comments come out
> properly in Javadoc.
>
> Regards
>
> Dibyendu
>
>
>
Re: restarting work on documenting the btree module ...
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
From: "Mike Matrigali" <mi...@sbcglobal.net>
> First here is a start at info about files in the index directory.
> Is this a good start. I would actually like to check this information
> into the source code, and am looking for some opinions about how best
> to do it. Currently it is just text, but ideally I would like to hook
> it up to html and the javadoc system some how.
Hi Mike. I guess the correct way would be create a package.html file and
check this in. I can do the conversion from your text.
> Below is a quick description of what the files do, see javadoc in the
> individual files for more explanation of each.
I would suggest that we update the documentation in each of Java files so
that all this becomes part of the Javadoc. I'd like to correct the existing
Javadoc comments and also add new new comments. Alternatively, if you add
the comments yourself, I can fix the html tags so that the comments come out
properly in Javadoc.
Regards
Dibyendu
Re: restarting work on documenting the btree module ...
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Mike Matrigali wrote:
> ok, should have time now to get back to this.
>
> First here is a start at info about files in the index directory.
> Is this a good start. I would actually like to check this information
> into the source code, and am looking for some opinions about how best
> to do it. Currently it is just text, but ideally I would like to hook
> it up to html and the javadoc system some how. Worst case I am just
> going to check it into a readme.txt in the appropriate directory unless
> there is some better suggestion. Unfortunately I don't have much
> html or javadoc expertise.
A package.html in the appropriate directory means that it will be picked
up by the javadoc automatically, e.g. see iapi.types.
Dan.
restarting work on documenting the btree module ...
Posted by Mike Matrigali <mi...@sbcglobal.net>.
ok, should have time now to get back to this.
First here is a start at info about files in the index directory.
Is this a good start. I would actually like to check this information
into the source code, and am looking for some opinions about how best
to do it. Currently it is just text, but ideally I would like to hook
it up to html and the javadoc system some how. Worst case I am just
going to check it into a readme.txt in the appropriate directory unless
there is some better suggestion. Unfortunately I don't have much
html or javadoc expertise.
Next I will look at the btree directory, probably tommorow.
And then eventually would like
to get back to the compare/contrast paper with Aries work this btree
is based on.
Text of a suggested readme.txt in the
java/engine/org/apache/derby/impl/store/access/btree/index
This directory implements the code used by the language layer to implement
SQL secondary indexes. The files here extend and use the classes in
the java/engine/org/apache/derby/impl/store/access/btree/index
directory to implement a locked btree index.
The key to understanding the class layout is to understand the public
store interfaces in
java/engine/org/apache/derby/iapi/store/access/conglomerate,
see the javadoc there. Basically it defines a shared interface used by
all access method interfaces. Currently derby implements a heap and a
btree index implementation. Every access method must implement all the
interfaces in that directory. Users of access methods use the same
interface
no matter what the underlying type or particular implementation of the
access method. Derby could support multiple types of btree index
implementation, which if done right should require no changes to actual
users
of the access methods.
In reality I would expect the interfaces to have to change some to support
a radically different kind of access method - like gist. But the
implementor
should enhance the interfaces in the conglomerate directory so that it can
then support all existing access methods.
Below is a quick description of what the files do, see javadoc in the
individual files for more explanation of each.
B2I.java
Implements the Conglomerate interface which has 2 rolls:
1) Is the object which is stored on disk which holds the store specific
information needed to access/describe the conglomerate. This
includes
information like the format id's of the columns, the conglomerate id
of the base table, the location of row location column.
2) Access to all the interface's start by making a call off the
Conglomerate interface. So for instance to get a scan on the
conglomerate you call B2I.openScan().
B2IController.java
Implements the ConglomerateController interface for the secondary index
implementation. The primary use of this interface is to insert rows
into
the tree.
B2ICostController.java
Implements the StoreCostController interface for the secondary index
implementation. The primary use of this interface is to provide costs
used by the query optimizer to use when choosing query plans. Provides
costs of things like fetch one row, how many rows in conglomerate, how
many rows between these 2 keys.
B2IFactory.java
Implments the ConglomerateFactory interface for the secondary index
implementation. This class makes this access method implementation
a module, and available through the ModuleControl system. Used to
create a new conglomerate and to bootstrap an existing B2I from disk
using
metadata stored to disk in a B2I.
B2IForwardScan.java
Implments the ScanManager interface. This supports setting up and
iterating through a set of rows while providing a start key, stop key,
and a set of AND and OR qualifiers to skip unwanted rows. Currently
derby only supports forward scans (but individual columns can have
descending order). This interface is also used to delete rows from
the conglomerate. Note that update is not supported, it must be
implemented as a delete, followed by an insert.
B2IMaxScan.java
This class implements an optimized interface to find the maximum row,
for a set of rows between an input start and stop key.
Isolation level implementation in the secondary index is done with data
only locking, ie. locks on secondary index rows are actually locks on the
data rows that they point to. The specifics of particular isolation levels
are hidden in various implementations of the BTreeLockingPolicy class. The
classes which do scans, deletes, and inserts don't have isolation specific
code, instead they make lock calls using BTreeLockingPolicy interfaces, and
then depending on the isolation level one of the following 4 classes does
the actual locking:
B2INoLocking.java
Basically does no locking. This is used when we know that logical locks
are already obtained so need not be requested again.
B2IRowLocking1.java
Implements the jdbc read uncommitted isolation level, using row locks.
No read locks are requested.
Holds write locks until end of transaction.
Extends B2IRowLocking2.
No previous key read locks are obtained.
B2IRowLocking2.java
Implements the jdbc read committed isolation level using row locks.
Releases read locks after obtaining them, in some cases uses optimized
locking interface to wait for lock grant and to instantaneously
release lock.
Holds write locks until end of transaction.
Extends B2IRowLockingRR.
B2IRowLockingRR.java
Implements the jdbc repeatable read isolation level using row locks.
Holds read and write locks until end of transaction.
No previous key read locks are obtained.
Extends B2IRowLocking3.
B2IRowLocking3.java
Implements the jdbc serializable isolation level using row locks.
Holds read and write locks until end of transaction.
Previous key locks are obtained to protect from phantom reads.
B2ITableLocking3.java
If table locking implements all isolation levels.
B2IStaticCompiledInfo.java
Information about the table that does not vary from one execution to
the next, can be compiled into a query plan and then sent back into
store to save lookup costs per execution of a query. See
openCompiledScan() for usage.
B2IUndo.java
Used to implement logical undo of btree insert and delete operations.
D_B2IController.java
Debugging class used to print debug information about B2I. Code here
can be used in SANE development builds but the class is not necessary
for a release so does not add footprint to a customer release.
See the DiagnosticableGeneric interface for more information.
Mike Matrigali wrote:
> I can help out with this, but probably will not get to it until next
> week, is that ok? Also let's move the discussion to some other
> subject.
>
> /mikem
>
> Dibyendu Majumdar wrote:
>
>> From: "Mike Matrigali" <mi...@sbcglobal.net>
>>
>>> 3) some extra functionality on btree side (not necessarily show
>>> stopper).
>>
>>
>>
>> Mike, I'd like to restart the work on documenting the Btree module.
>> Would you have time to add to any of your previous comments?
>> If you could provide a brief note on the various Classes and which one
>> does
>> what, I can this further by reading up the code/comments.
>>
>> Regards
>>
>>
>>
>>
>
>
Re: Planning for a 10.1 release
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I can help out with this, but probably will not get to it until next
week, is that ok? Also let's move the discussion to some other
subject.
/mikem
Dibyendu Majumdar wrote:
> From: "Mike Matrigali" <mi...@sbcglobal.net>
>
>>3) some extra functionality on btree side (not necessarily show stopper).
>
>
> Mike, I'd like to restart the work on documenting the Btree module.
> Would you have time to add to any of your previous comments?
> If you could provide a brief note on the various Classes and which one does
> what, I can this further by reading up the code/comments.
>
> Regards
>
>
>
>
Re: Planning for a 10.1 release
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
From: "Mike Matrigali" <mi...@sbcglobal.net>
> 3) some extra functionality on btree side (not necessarily show stopper).
Mike, I'd like to restart the work on documenting the Btree module.
Would you have time to add to any of your previous comments?
If you could provide a brief note on the various Classes and which one does
what, I can this further by reading up the code/comments.
Regards
Re: Planning for a 10.1 release
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I would like to finish up work on DERBY-132 for this release, I
am planning to be done by 5/31. Remaining work includes:
1) upgrade support - necessary for release. expect commit for
this today or tommorow.
2) more testing (not a show stopper)
3) some extra functionality on btree side (not necessarily show stopper).
/mikem
Andrew McIntyre wrote:
> On 5/24/05, Shreyas Kaushik <Sh...@sun.com> wrote:
>
>>Andrew McIntyre wrote:
>>
>>
>>>Hello derby-dev,
>>>
>>>Now that there have been some significant new contributions to Derby
>>>since 10.0.2.1 was released, I think we should begin planning for a
>>>10.1 release. As promised earlier, I'll volunteer to be release
>>>manager. So, here goes:
>>>
>>>1) Are there any new features or significant bugfixes near completion
>>>that should be in the 10.1 release? Dan mentioned that he would like
>>>to have his JSR-169 work included, Tomohito's fix for Derby-167 looks
>>>nearly complete, and David V.C. has a couple of items that look like
>>>they might be done soon. Any estimates on when these will be
>>>completed? Anything else not mentioned here?
>>>
>>
>>Derby-31. This would be a good one to have for this release.
>>
>>~ Shreyas
>
>
> I'm thinking that in the interests of getting an official release out
> with the Derby client, I'd like to aim for a release in about two
> weeks or so.
>
> Derby-31 is currently assigned to Oyvind Bakksjo. Are you assisting
> him with this issue? Do you have an estimate when the work for this
> might be complete?
>
> Is anyone else working on features or JIRA bugs that they feel should
> be in this release?
>
> - Mamta's updatable result sets for Network Server changes have been
> checked in, as have Lance's script changes.
>
> - Jeremy, in what timeframe do you think you will have a working
> prototype for the Datasource API changes? If you need help running
> tests against the prototype, please email me, I can help out with
> that. But, it's not clear to me that this is something that must be in
> the 10.1 release. Is this something that could be deferred to a 10.2
> (or even a 10.1.x) release? It's not unusual to manage API changes at
> release boundaries, so I don't think that having to support the
> current Datasource API going into the future is necessarily a reason
> to hold up this release.
>
> - Scanning through the list, I noticed Army mentioned basic XML
> support. Army, any estimate on when this might be contributed? Or is
> this for a future release?
>
> Many people are also assigned JIRA issues. So, if you currently have a
> JIRA issue assigned to you that you feel is a showstopper for a 10.1
> release, please speak up!
>
> andrew
>
Re: Planning for a 10.1 release
Posted by Suresh Thalamati <su...@gmail.com>.
Hi Andrew,
Almost done with following two issues I had been working on:
DERBY-96 - transaction log checksum feature to recognize partial log
record writes that occur because
of out-of order writes.
DERBY-101 - increasing the possible log file id's from 2^22 -1 to 2^33 -1 .
I have posted couple of patches related to the above bugs to the list,
but not yet committed. I am hoping they will be
committed in a day or two.
Thanks
-suresh
Andrew McIntyre wrote:
>On 5/24/05, Shreyas Kaushik <Sh...@sun.com> wrote:
>
>
>>Andrew McIntyre wrote:
>>
>>
>>
>>>Hello derby-dev,
>>>
>>>Now that there have been some significant new contributions to Derby
>>>since 10.0.2.1 was released, I think we should begin planning for a
>>>10.1 release. As promised earlier, I'll volunteer to be release
>>>manager. So, here goes:
>>>
>>>1) Are there any new features or significant bugfixes near completion
>>>that should be in the 10.1 release? Dan mentioned that he would like
>>>to have his JSR-169 work included, Tomohito's fix for Derby-167 looks
>>>nearly complete, and David V.C. has a couple of items that look like
>>>they might be done soon. Any estimates on when these will be
>>>completed? Anything else not mentioned here?
>>>
>>>
>>>
>>Derby-31. This would be a good one to have for this release.
>>
>>~ Shreyas
>>
>>
>
>I'm thinking that in the interests of getting an official release out
>with the Derby client, I'd like to aim for a release in about two
>weeks or so.
>
>Derby-31 is currently assigned to Oyvind Bakksjo. Are you assisting
>him with this issue? Do you have an estimate when the work for this
>might be complete?
>
>Is anyone else working on features or JIRA bugs that they feel should
>be in this release?
>
>- Mamta's updatable result sets for Network Server changes have been
>checked in, as have Lance's script changes.
>
>- Jeremy, in what timeframe do you think you will have a working
>prototype for the Datasource API changes? If you need help running
>tests against the prototype, please email me, I can help out with
>that. But, it's not clear to me that this is something that must be in
>the 10.1 release. Is this something that could be deferred to a 10.2
>(or even a 10.1.x) release? It's not unusual to manage API changes at
>release boundaries, so I don't think that having to support the
>current Datasource API going into the future is necessarily a reason
>to hold up this release.
>
>- Scanning through the list, I noticed Army mentioned basic XML
>support. Army, any estimate on when this might be contributed? Or is
>this for a future release?
>
>Many people are also assigned JIRA issues. So, if you currently have a
>JIRA issue assigned to you that you feel is a showstopper for a 10.1
>release, please speak up!
>
>andrew
>
>
>
Re: Planning for a 10.1 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On 5/24/05, Shreyas Kaushik <Sh...@sun.com> wrote:
> Andrew McIntyre wrote:
>
> >Hello derby-dev,
> >
> >Now that there have been some significant new contributions to Derby
> >since 10.0.2.1 was released, I think we should begin planning for a
> >10.1 release. As promised earlier, I'll volunteer to be release
> >manager. So, here goes:
> >
> >1) Are there any new features or significant bugfixes near completion
> >that should be in the 10.1 release? Dan mentioned that he would like
> >to have his JSR-169 work included, Tomohito's fix for Derby-167 looks
> >nearly complete, and David V.C. has a couple of items that look like
> >they might be done soon. Any estimates on when these will be
> >completed? Anything else not mentioned here?
> >
>
> Derby-31. This would be a good one to have for this release.
>
> ~ Shreyas
I'm thinking that in the interests of getting an official release out
with the Derby client, I'd like to aim for a release in about two
weeks or so.
Derby-31 is currently assigned to Oyvind Bakksjo. Are you assisting
him with this issue? Do you have an estimate when the work for this
might be complete?
Is anyone else working on features or JIRA bugs that they feel should
be in this release?
- Mamta's updatable result sets for Network Server changes have been
checked in, as have Lance's script changes.
- Jeremy, in what timeframe do you think you will have a working
prototype for the Datasource API changes? If you need help running
tests against the prototype, please email me, I can help out with
that. But, it's not clear to me that this is something that must be in
the 10.1 release. Is this something that could be deferred to a 10.2
(or even a 10.1.x) release? It's not unusual to manage API changes at
release boundaries, so I don't think that having to support the
current Datasource API going into the future is necessarily a reason
to hold up this release.
- Scanning through the list, I noticed Army mentioned basic XML
support. Army, any estimate on when this might be contributed? Or is
this for a future release?
Many people are also assigned JIRA issues. So, if you currently have a
JIRA issue assigned to you that you feel is a showstopper for a 10.1
release, please speak up!
andrew
Re: Planning for a 10.1 release
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Andrew McIntyre wrote:
>Hello derby-dev,
>
>Now that there have been some significant new contributions to Derby
>since 10.0.2.1 was released, I think we should begin planning for a
>10.1 release. As promised earlier, I'll volunteer to be release
>manager. So, here goes:
>
>1) Are there any new features or significant bugfixes near completion
>that should be in the 10.1 release? Dan mentioned that he would like
>to have his JSR-169 work included, Tomohito's fix for Derby-167 looks
>nearly complete, and David V.C. has a couple of items that look like
>they might be done soon. Any estimates on when these will be
>completed? Anything else not mentioned here?
>
>
Derby-31. This would be a good one to have for this release.
~ Shreyas
>2) Are there any currently opened JIRA entries that should be
>considered showstoppers for this release? Any upgrade issues
>definitely need to be sorted out and tested, maybe we should have a
>JIRA for this. Documentation of new features should be finalized. I
>think there may already be a JIRA entry for this.
>
>3) Which bugs would be nice-to-have in this release but are not
>showstoppers? I personally would like to see the patch for Derby-1
>committed.
>
>4) Are there any issues surrounding the client that should be
>addressed before it is released? This deserves its own thread, and
>there's already one started here:
>
>http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/%3c42784236.70504@apache.org%3e
>
>That thread got quiet, but I'll respond to that mail to keep the
>discussion going.
>
>5) Are there any changes to the packaging that people would like to
>see for this release?
>
>Feel free to add to this list and I'll keep track of all the responses.
>
>andrew
>
>
Re: Planning for a 10.1 release
Posted by Dibyendu Majumdar <di...@mazumdar.demon.co.uk>.
----- Original Message -----
From: "Andrew McIntyre" <mc...@gmail.com>
DERBY-246 - XA on Network Server bug - Kathey / Dibyendu - is this a
showstopper? needs testing.
Hi,
I don't think this is a show stopper.
However, another problem I found while testing this (see DERBY-325) seems a
show stopper to me.
Regards
Dibyendu
Re: Planning for a 10.1 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Andrew McIntyre wrote:
>Bug fixes nominated for the release:
>
>
>
[snip]
>DERBY-213 - Kathey
>
>
DERBY-213 is not a show stopper and may not get in on time. You can
take it off the list.
Thanks
Kathey
Re: Planning for a 10.1 release
Posted by Army <qo...@sbcglobal.net>.
Andrew McIntyre wrote:
> Based on the feedback so far, I wanted to give a current status as we
> head towards a release:
[ snip ]
> please speak up if something you feel should
> be included in the release is not on this list.
DERBY-121 looks like a straightforward fix and will affect any users who are
dealing with very large LOB data (ex. length > 2^23 chars for a clob).
I have coded the fix and a corresponding test, but need to run derbyall before
posting. I wouldn't call this a show-stopper by any means, but I do think it's
something that should go into 10.1.
I'm also looking at DERBY-194 and DERBY-319, which are minor metadata changes.
I have patches for both, but am still in the process of running derbyall.
Again, both are fairly minor and should _not_ be considered show-stoppers.
Army
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Andrew McIntyre wrote:
> Based on the feedback so far, I wanted to give a current status as we
> head towards a release:
I would add that DERBY-322 needs to be fixed before the release.
http://issues.apache.org/jira/browse/DERBY-322
Dan.
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
Andrew McIntyre wrote:
> Based on the feedback so far, I wanted to give a current status as we
> head towards a release:
>
> Unresolved issues:
>
> Datasource unification - Jeremy - any update? are you going to try and
> get a patch in for this release?
Yes - ETA 6/3 due to coding ban over Memorial Day weekend.
--
Jeremy
Re: Planning for a 10.1 release
Posted by Andrew McIntyre <mc...@gmail.com>.
Based on the feedback so far, I wanted to give a current status as we
head towards a release:
Unresolved issues:
Datasource unification - Jeremy - any update? are you going to try and
get a patch in for this release?
DERBY-246 - XA on Network Server bug - Kathey / Dibyendu - is this a
showstopper? needs testing.
New features in the works:
JSR-169 Support - Dan - 5/30-5/31
DERBY-132 - Mike - 5/31
XML support - Army - patch in review
Synonym support - Satheesh - ?
Bug fixes nominated for the release:
DERBY-180 - Andrew - patch submitted
DERBY-213 - Kathey
DERBY-247 - Lance / Andrew (demos need to support Derby client)
DERBY-255 - Kathey - patch committed
DERBY-265 - Sunitha - patch committed
DERBY-308 - Tomohito
DERBY-318 - Tomohito
Other bugs that look close to resolution:
DERBY-205 - Dag
DERBY-230 - Øystein / Dag
Doc / Release Note:
DERBY-305 - David - patch needs work
Packaging / Other:
Document on making a release / ant targets - Andrew
I suspect there may be other doc issues that need to be addressed that
are not listed here. Also, there has been so much mail that I likely
have missed something, so please speak up if something you feel should
be included in the release is not on this list.
Thanks,
andrew
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Andrew McIntyre wrote:
> Hello derby-dev,
>
> Now that there have been some significant new contributions to Derby
> since 10.0.2.1 was released, I think we should begin planning for a
> 10.1 release. As promised earlier, I'll volunteer to be release
> manager. So, here goes:
>
> 1) Are there any new features or significant bugfixes near completion
> that should be in the 10.1 release? Dan mentioned that he would like
> to have his JSR-169 work included, Tomohito's fix for Derby-167 looks
> nearly complete, and David V.C. has a couple of items that look like
> they might be done soon. Any estimates on when these will be
> completed? Anything else not mentioned here?
I hoping to get the JSR169 into a working state by the end of this
(three day) weekend.
> 5) Are there any changes to the packaging that people would like to
> see for this release?
I would like to see a writeup on how to perform a release, hopefully
most of the work can be driven by ant targets.
Dan.
Re: Planning for a 10.1 release
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
"experimental" wording removed, committed revision 178292. Change will
become visible on the web site with the next rsync to www.apache.org
(currently scheduled for every 4 hours).
-jean
Jean T. Anderson wrote:
> Daniel John Debrunner wrote:
>
>> 6) The 10.1 current manuals have an *experimental* format according to
>>
>> http://incubator.apache.org/derby/manuals/index.html#10.1+Alpha+Manuals
>>
>> Not sure what is experimental about their current format, but this
>> should be resolved to a non-experimental format.
>
>
> Jeff posted numerous disclaimers about the initial format.
>
> I'm happy to remove the word "experimental". Experience on other apache
> lists demonstrates that this may be "it". Of course, anyone should feel
> free to jump in a help tweak the format.
>
> -jean
Re: Planning for a 10.1 release
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Daniel John Debrunner wrote:
> 6) The 10.1 current manuals have an *experimental* format according to
>
> http://incubator.apache.org/derby/manuals/index.html#10.1+Alpha+Manuals
>
> Not sure what is experimental about their current format, but this
> should be resolved to a non-experimental format.
Jeff posted numerous disclaimers about the initial format.
I'm happy to remove the word "experimental". Experience on other apache
lists demonstrates that this may be "it". Of course, anyone should feel
free to jump in a help tweak the format.
-jean
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Andrew McIntyre wrote:
> Hello derby-dev,
>
> Now that there have been some significant new contributions to Derby
> since 10.0.2.1 was released, I think we should begin planning for a
> 10.1 release. As promised earlier, I'll volunteer to be release
> manager. So, here goes:
[snip]
>
> Feel free to add to this list and I'll keep track of all the responses.
6) The 10.1 current manuals have an *experimental* format according to
http://incubator.apache.org/derby/manuals/index.html#10.1+Alpha+Manuals
Not sure what is experimental about their current format, but this
should be resolved to a non-experimental format.
Thanks,
Dan.
Re: Planning for a 10.1 release
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Well, users would always want to have message text for exceptions. There
may be need to have this for Derby client, to turn off automatic message
text retrieval. Getting an error message to client may start a
transaction on the server. This issue doesn't arise for embedded client.
Satheesh
Jeremy Boynes wrote:
> I think retrieveMessageText and trace apply to both.
>
> The user should have the choice over whether the text is returned in
> an exception or not irrespective of how they connect.
>
> Trace is a feature that works differently.
>
>> I would like to see a complete proposal that passes all tests as soon
>> as possible. I am worried the devil may be in the details ... :-)
>>
>
> Working on it :-)
> I have the unified Driver working and have unit tests for it. I will
> try to commit later tonight when I can get that computer connected to
> the network.
>
> This is all in a separate branch - I would appreciate some help
> getting the test suite to run with it.
>
> --
> Jeremy
>
>
>
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
Satheesh Bandaram wrote:
> Actually 'retrieveMessageText' property would only apply to Derby
> client. So is '*securityMechanism*' and tracing properties. Embedded
> driver doesn't have the tracing mechanism that is part of Derby client.
>
I think retrieveMessageText and trace apply to both.
The user should have the choice over whether the text is returned in an
exception or not irrespective of how they connect.
Trace is a feature that works differently.
> I would like to see a complete proposal that passes all tests as soon as
> possible. I am worried the devil may be in the details ... :-)
>
Working on it :-)
I have the unified Driver working and have unit tests for it. I will try
to commit later tonight when I can get that computer connected to the
network.
This is all in a separate branch - I would appreciate some help getting
the test suite to run with it.
--
Jeremy
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
Daniel John Debrunner wrote:
>>Early implementation is one thing, but you want to get the public
>>interfaces right, or at least easily extensible, from the start so you
>>don't end up regretting something forever.
>
>
> True, but in this case the public api is defined by class name(s) (that
> implements DataSource) and a set of JeavBean properties, and what those
> properties mean and how they interact with each other.
>
> Thus we should not have a Java code strawman but instead a table of
> properties, like table 9.1 in section 9.4 in JDBC 3.0 spec.
> Though in the unified case the table would need additional columns to
> indicate what they mean in each mode, emebedded, client etc.
>
> I think that would be the best way to look at this, see how many
> properties are common to each mode, how many could confuse users, e.g.
> portNumber for embeddded (especially when running embedded with an
> embedded network server). How complicated any rules are. etc.
>
> Property overload for the user is what I'm concerned about.
>
I JavaDoc'ed the properties in the code including a description of how
they interact (to my knowledge at least). It seems fairly logical to me now.
I made the ConnectionFactory impl pluggable by the user with a default
impl that chooses embedded or client based on whether serverName is set
or not. I think the only redundant property is portNumber.
It does not yet support the client tracing options - I held off on that
because if we are going to unify we should support it in both client and
embedded modes and I don't think embedded has that (or if it does it is
set up differently).
Similarly with things like message text, database password, encryption,
result set holdability and so forth - they should work the same
regardless of whether the server in embedded or remote.
I still need to do the unified Driver impl - ran out of time this
weekend but may be able to get to it tomorrow (I have all day in a tin can).
I also ran into what appear a couple of quirks in the client but will
move those to a separate thread.
--
Jeremy
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jeremy Boynes wrote:
[snip]
> Well, there is a strawman in the branch and we've not been discussing it
> long.
[snip]
> Early implementation is one thing, but you want to get the public
> interfaces right, or at least easily extensible, from the start so you
> don't end up regretting something forever.
True, but in this case the public api is defined by class name(s) (that
implements DataSource) and a set of JeavBean properties, and what those
properties mean and how they interact with each other.
Thus we should not have a Java code strawman but instead a table of
properties, like table 9.1 in section 9.4 in JDBC 3.0 spec.
Though in the unified case the table would need additional columns to
indicate what they mean in each mode, emebedded, client etc.
I think that would be the best way to look at this, see how many
properties are common to each mode, how many could confuse users, e.g.
portNumber for embeddded (especially when running embedded with an
embedded network server). How complicated any rules are. etc.
Property overload for the user is what I'm concerned about.
Dan.
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
Daniel John Debrunner wrote:
> Though maybe the internal re-work could be separated into a follow on
> project, a common data source api could still use the current internal
> mechanism.
>
That's what I would do for an initial impl.
>
>
>>I think the only question is
>>whether they are a good idea or not: if they are a good idea then making
>>the changes now in this release is very desirable to avoid future
>>changes in the network client. Surely it should be possible to
>>evaluate reasonably quickly whether the changes result in a simpler and
>>improved user experience. As you may have guessed, I think they do :-)
>
>
> Not sure how we would evaulate quickly, I'm not convinced the scheme is
> easier and it may be more confusing to users.
>
> The other issue is do we hold up releasing 10.1 and the derby client to
> resolve this? Especially as we don't have any actual code or patch
> implementing it. How long would we wait and how does that tie into
> release early, release often?
>
Well, there is a strawman in the branch and we've not been discussing it
long.
> And that brings me to one solution, release soon without this change (as
> it doesn't exist), release once it does exist, and then let the users
> tell us which approach is better. Covers release early/often and the
> darwin aspect of open source.
>
Early implementation is one thing, but you want to get the public
interfaces right, or at least easily extensible, from the start so you
don't end up regretting something forever.
This is new functionality that was dropped into the project and
questions were raised fairly quickly. Rushing out a first release (and
hence committing to an API) without clear answers does no-one any good,
neither users nor developers.
--
Jeremy
Re: Planning for a 10.1 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David Jencks wrote:
>
>
> Jeremy's proposed changes for the unified DataSource are extremely
> unlikely to break anything (IMNSHO) since they just move stuff around a
> little bit without changing how it works.
Actually it's more than just moving code, part of Jeremy's proposal is
switching how connections are created, from an internal scheme based
upon JDBC URLs to an internal scheme based upon JavaBeans(DataSource).
Since getting connections and booting databases is completely designed
around the existing scheme, such a change is more complicated that it looks.
Though maybe the internal re-work could be separated into a follow on
project, a common data source api could still use the current internal
mechanism.
> I think the only question is
> whether they are a good idea or not: if they are a good idea then making
> the changes now in this release is very desirable to avoid future
> changes in the network client. Surely it should be possible to
> evaluate reasonably quickly whether the changes result in a simpler and
> improved user experience. As you may have guessed, I think they do :-)
Not sure how we would evaulate quickly, I'm not convinced the scheme is
easier and it may be more confusing to users.
The other issue is do we hold up releasing 10.1 and the derby client to
resolve this? Especially as we don't have any actual code or patch
implementing it. How long would we wait and how does that tie into
release early, release often?
And that brings me to one solution, release soon without this change (as
it doesn't exist), release once it does exist, and then let the users
tell us which approach is better. Covers release early/often and the
darwin aspect of open source.
Dan.
Re: Planning for a 10.1 release
Posted by David Jencks <dj...@gluecode.com>.
On May 19, 2005, at 4:39 PM, Kathey Marsden wrote:
> Jeremy Boynes wrote:
>
>> I would like to get to resolution on the unified DataSource issue
>> before we release. If we go that way then these changes will be
>> irrelevant because of the unified API; if we don't then I would like
>> to follow through with the Pooled/XA changes.
>>
> I was thinking something less dramatic to get us into a state where we
> could release, like backing out the changes or moving
> ClientBaseDataSource to the jdbc directory. Then the whole unified
> DataSource issue can be given more thought later.
> But that might just be my little thinking again #:)
>
Jeremy's proposed changes for the unified DataSource are extremely
unlikely to break anything (IMNSHO) since they just move stuff around a
little bit without changing how it works. I think the only question is
whether they are a good idea or not: if they are a good idea then
making the changes now in this release is very desirable to avoid
future changes in the network client. Surely it should be possible to
evaluate reasonably quickly whether the changes result in a simpler and
improved user experience. As you may have guessed, I think they do :-)
Many thanks,
david jencks
Re: Planning for a 10.1 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Jeremy Boynes wrote:
> I would like to get to resolution on the unified DataSource issue
> before we release. If we go that way then these changes will be
> irrelevant because of the unified API; if we don't then I would like
> to follow through with the Pooled/XA changes.
>
I was thinking something less dramatic to get us into a state where we
could release, like backing out the changes or moving
ClientBaseDataSource to the jdbc directory. Then the whole unified
DataSource issue can be given more thought later.
But that might just be my little thinking again #:)
Re: Planning for a 10.1 release
Posted by Jeremy Boynes <jb...@apache.org>.
Kathey Marsden wrote:
>
> Jeremy could you comment on the changes that you made to
> ClientDataSource? Is there follow up work that you still need to do
> there for the release?
>
> r168355 | jboynes | 2005-05-05 10:00:08 -0700 (Thu, 05 May 2005) | 1 line
>
> move all generic implementation into ClientBaseDataSource
Moved generic properties (e.g. description) into the base class in
anticipation of refactoring the class hierarchy so that the Pooled and
XA implementations did not need to subclass the regualar DataSource
> ------------------------------------------------------------------------
> r168336 | jboynes | 2005-05-05 07:35:57 -0700 (Thu, 05 May 2005) | 1 line
>
> code cleanup on client DataSource impls
>
Cosmetic followup from the code reformat (e.g. replacing fully qualified
class names with imports)
I would like to get to resolution on the unified DataSource issue before
we release. If we go that way then these changes will be irrelevant
because of the unified API; if we don't then I would like to follow
through with the Pooled/XA changes.
--
Jeremy
Re: Planning for a 10.1 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Andrew McIntyre wrote:
>Hello derby-dev,
>
>1) Are there any new features or significant bugfixes near completion
>that should be in the 10.1 release? Dan mentioned that he would like
>to have his JSR-169 work included, Tomohito's fix for Derby-167 looks
>nearly complete, and David V.C. has a couple of items that look like
>they might be done soon. Any estimates on when these will be
>completed? Anything else not mentioned here?
>
>
>
Jeremy could you comment on the changes that you made to
ClientDataSource? Is there follow up work that you still need to do
there for the release?
r168355 | jboynes | 2005-05-05 10:00:08 -0700 (Thu, 05 May 2005) | 1 line
move all generic implementation into ClientBaseDataSource
------------------------------------------------------------------------
r168336 | jboynes | 2005-05-05 07:35:57 -0700 (Thu, 05 May 2005) | 1 line
code cleanup on client DataSource impls
Kathey