Daniel John Debrunner [EMAIL PROTECTED] writes:
David Van Couvering wrote:
Good news Lance, thanks, I was getting worried if we were going to have
to regularly change column order and break existing applications/IDEs/etc.
Hopefully we don't have any documented Derby specific additional
Andrew McIntyre wrote:
On 6/20/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Mike Matrigali wrote:
I would like to see the fix for DERBY-1392 included in the 10.1.3
release if there is a second release candidate. While the bug
is an edge error case, the result is a corrupt db. I believe
setEmbeddedCP.ksh and setNetworkCleitn.ksh does not work or gives wrong error
message
-
Key: DERBY-1436
URL: http://issues.apache.org/jira/browse/DERBY-1436
Project: Derby
Type: Bug
[Auto-generated mail]
*Derby* 416051/2006-06-21 19:46:07 CEST
*derbyall*
Failed TestsOK Skip Duration Platform
---
*Jvm: 1.6*
15715700 0 106.56% SunOS-5.10_i86pc-i386
Details in
[ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]
Kristian Waagan reassigned DERBY-1417:
--
Assign To: Kristian Waagan
Add new, lengthless overloads to the streaming api
--
Key:
[
http://issues.apache.org/jira/browse/DERBY-1435?page=comments#action_12417279 ]
Øystein Grøvlen commented on DERBY-1435:
I have sometimes seen the same error message in another context. See
DERBY-637. No triggers involved in my case and not
[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ]
Knut Anders Hatlen reassigned DERBY-1393:
-
Assign To: Knut Anders Hatlen
PreparedStatement.setObject(Object,int,int) should throw for unsupported types
Hello,
I'm working on DERBY-1417; adding new lengthless overloads to the
streaming API. So far, I have only been looking at implementing this in
the embedded driver. Based on some comments in the code, I have a few
questions and observations regarding truncation of trailing blanks in
the
Add new LRU Cache Manager
-
Key: DERBY-1437
URL: http://issues.apache.org/jira/browse/DERBY-1437
Project: Derby
Type: Improvement
Components: Services
Reporter: Gokul Soundararajan
Assigned to: Gokul Soundararajan
In databases,
David Van Couvering wrote:
Rick Hillegas wrote:
Hi David,
I had a couple more comments on the compatibility commitments.
Cheers-Rick
- Changes to stored procedures: We will have to change column order if
we add Derby-specific columns to a metadata ResultSet and then a later
JDBC
Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader, cares about. I don't think the
reader is particularly concerned about our transition to dita. If that
is what
[ http://issues.apache.org/jira/browse/DERBY-1361?page=all ]
Andreas Korneliussen updated DERBY-1361:
Attachment: DERBY-1361v2.diff
DERBY-1361v2.stat
Attaching an updated patch. Two more master files had to be updated because of
Kristian Waagan wrote:
Hello,
I'm working on DERBY-1417; adding new lengthless overloads to the
streaming API. So far, I have only been looking at implementing this in
the embedded driver. Based on some comments in the code, I have a few
questions and observations regarding truncation of
Hi David,
You might want to wrap the test in a custom Ant Task. These are
described in the Ant manual: Developing with Ant-Writing Your Own
Task. You can then check the return status of the task and fail the
build if appropriate.
Regards,
-Rick
David Van Couvering wrote:
Hm, a build-time
[ http://issues.apache.org/jira/browse/DERBY-1313?page=all ]
Fernanda Pizzorno updated DERBY-1313:
-
Attachment: derby-1313v1.pdf
The attached document (derby-1313v1.pdf) contains a short description of the
work done in DERBY-1313 and DERBY-1374,
[
http://issues.apache.org/jira/browse/DERBY-1395?page=comments#action_12417318 ]
Deepa Remesh commented on DERBY-1395:
-
I had seen the first scenario (both connection and statement closed) in
jdbcapi/checkDataSource.java.This is in the checkConnection
[ http://issues.apache.org/jira/browse/DERBY-955?page=all ]
Olav Sandstaa updated DERBY-955:
Attachment: bug955_derbyall.diff
This patch contains fixes to the following tests that are failing when
running derbyall with jdk 1.6:
* derbynetclientmats:
[ http://issues.apache.org/jira/browse/DERBY-955?page=all ]
Olav Sandstaa updated DERBY-955:
Derby Info: [Patch Available]
Get derbyall on jdk1.6
--
Key: DERBY-955
URL:
Rick Hillegas wrote:
Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader, cares about. I don't think the
reader is particularly concerned about our transition to dita.
[
http://issues.apache.org/jira/browse/DERBY-1435?page=comments#action_12417323 ]
Deepa Remesh commented on DERBY-1435:
-
Thanks for looking into this Suresh. Now, I can see this from the traces too.
We are re-using the prepared statement after table t1
On 6/22/06, Øystein Grøvlen (JIRA) derby-dev@db.apache.org wrote:
I have sometimes seen the same error message in another context. See
DERBY-637. No triggers involved in my case and not easily reproduced (but I
have seen it several times). I had to shutdown and restart the database to
make
Jean T. Anderson wrote:
Rick Hillegas wrote:
Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader, cares about. I don't think the
reader is particularly concerned
Text written by SQLException.toString differs between client and embedded driver
Key: DERBY-1438
URL: http://issues.apache.org/jira/browse/DERBY-1438
Project: Derby
Type: Improvement
Rick Hillegas wrote:
David Van Couvering wrote:
Rick Hillegas wrote:
Hi David,
I had a couple more comments on the compatibility commitments.
Cheers-Rick
- Changes to stored procedures: We will have to change column order if
we add Derby-specific columns to a metadata ResultSet
Knut Anders Hatlen wrote:
Daniel John Debrunner [EMAIL PROTECTED] writes:
David Van Couvering wrote:
Good news Lance, thanks, I was getting worried if we were going to have
to regularly change column order and break existing applications/IDEs/etc.
Hopefully we don't have any documented
Rick Hillegas wrote:
Jean T. Anderson wrote:
Rick Hillegas wrote:
Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader, cares about. I don't think the
reader is
[ http://issues.apache.org/jira/browse/DERBY-1438?page=all ]
David Van Couvering reassigned DERBY-1438:
--
Assign To: David Van Couvering
Text written by SQLException.toString differs between client and embedded
driver
[
http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12417330 ]
David Van Couvering commented on DERBY-1438:
I'll take a look at this and see what I can do. Thanks, Olav.
Text written by SQLException.toString differs between
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Jean T. Anderson wrote:
Rick Hillegas wrote:
Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader,
ij running with client driver and jdk 1.6 omits chained exceptions in error
messages
Key: DERBY-1440
URL: http://issues.apache.org/jira/browse/DERBY-1440
Project: Derby
Type: Bug
David Van Couvering wrote:
Rick Hillegas wrote:
I can see that Private Stable applies to the client/server api. These
apis should remain forward/backward compatible within a release
family. Do Private Stable interfaces turn up in other situations?
Yes, that's right. I wonder if
[
http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12417334 ]
Olav Sandstaa commented on DERBY-1438:
--
Personally, I prefer the text written by the embedded driver (SQL Exception:)
over the text written by the client driver
Kathey Marsden wrote:
Mike Matrigali wrote:
I would like to see the fix for DERBY-1392 included in the 10.1.3
release if there is a second release candidate. While the bug
is an edge error case, the result is a corrupt db. I believe
there is little risk as again the path is not one usually
Mike Matrigali wrote:
I would like to see the fix for DERBY-1392 included in the 10.1.3
release if there is a second release candidate. While the bug
is an edge error case, the result is a corrupt db. I believe
there is little risk as again the path is not one usually taken.
The change has
Andrew McIntyre wrote:
On 6/20/06, Kathey Marsden [EMAIL PROTECTED] wrote:
Mike Matrigali wrote:
I would like to see the fix for DERBY-1392 included in the 10.1.3
release if there is a second release candidate. While the bug
is an edge error case, the result is a corrupt db. I believe
[ http://issues.apache.org/jira/browse/DERBY-1429?page=all ]
Mike Matrigali updated DERBY-1429:
--
Component: Services
(was: Store)
This issue should be handled by the monitor, not the store.
Additional vulnerability to
--- Rick Hillegas [EMAIL PROTECTED] wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Jean T. Anderson wrote:
Rick Hillegas wrote:
Thanks, Jean. The Edition line turns up in the
visible text which
appears in the printed document. That makes me
[ http://issues.apache.org/jira/browse/DERBY-1343?page=all ]
Mike Matrigali updated DERBY-1343:
--
Component: (was: Store)
this is an issue with the system catalogs, from discussions on list it looks
like not a store issue.
It is possible to have
[ http://issues.apache.org/jira/browse/DERBY-1156?page=all ]
Mike Matrigali updated DERBY-1156:
--
i reviewed and tested reencrypt_3.diff patch. it looks fine, i will let you
commit. Still would like to see more testing, especially exercising the abort
Mike Matrigali (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1156?page=all ]
Mike Matrigali updated DERBY-1156:
--
i reviewed and tested reencrypt_3.diff patch. it looks fine, i will let you commit. Still would like to see more testing,
Andrew McIntyre wrote:
If we have another release candidate, and assuming that the relevant
fixes for it can be committed by Friday, are those testing the release
candidate comfortable with a 72-hour turnaround on the vote for the
new release candidate or will we need another two weeks?
I
+1
Based on test results:
http://www.multinet.no/~solberg/public/Apache/index.html
Andreas
Jeff Levitt wrote:
snip
As the person who contributed the DITA-converted
documentation, I can tell you I didn't bump the
edition up based on that. I believe the pre-DITA
documentation already said Second Edition.
The pre-DITA (10.0) doc source says First Edition:
+1
Regards,
-Rick
Jean T. Anderson wrote:
Jeff Levitt wrote:
snip
As the person who contributed the DITA-converted
documentation, I can tell you I didn't bump the
edition up based on that. I believe the pre-DITA
documentation already said Second Edition.
The pre-DITA (10.0) doc
[
http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417349 ]
Kathey Marsden commented on DERBY-1275:
---
I was wondering if anyone had any thoughts on how to implement this
improvement to
provide a way to enable client tracing
Last week, Sun Microsystems announced that it will bundle Derby with the
next major release of the reference jdk, Java SE 6, also known as
Mustang or jdk1.6. If you download the latest Mustang build, you will
see that it contains our Derby 10.2.0.3 snapshot in the db directory
parallel to lib
Rick Hillegas (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1271?page=all ]
Rick Hillegas updated DERBY-1271:
-
Attachment: derby-1271_copyrights.diff
Attaching derby-1271_copyrights.diff. This adjusts dates in the visible
Rick Hillegas wrote:
The JCP requires that our JDBC4-exposing release can not be generally
available until the JDBC4 specification is finalized.
Is this something that the Derby community is bound to?
Here are proposed dates for 10.2 milestones:
August 10 - Feature work committed. 10.2
Daniel John Debrunner wrote:
Kristian Waagan wrote:
Hello,
I'm working on DERBY-1417; adding new lengthless overloads to the
streaming API. So far, I have only been looking at implementing this in
the embedded driver. Based on some comments in the code, I have a few
questions and
David Van Couvering wrote:
Hi, Kathey, my silence (and I'm guessing the silence of others) was
general approval of your comments. Did you update the page? I didn't
see any change notifications fly by.
Finally did it.
What kind of clarification are you looking for? I'm afraid I'm
Hi Kathey,
Thanks for raising these issues. Here are some clarifications.
Regards,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
The JCP requires that our JDBC4-exposing release can not be generally
available until the JDBC4 specification is finalized.
Is this something that the
Rick Hillegas wrote:
Last week, Sun Microsystems announced that it will bundle Derby with the
next major release of the reference jdk, Java SE 6, also known as
Mustang or jdk1.6.
To be precise, Sun Microsystems announced that it will bundle Java DB
with Mustang.
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What happens between September 15 and End of October on the 10.2 branch?
If we fix critical bugs during that time in the 10.2 branch can't they
go into the release end of October?
They should be able to. Since we won't
Allow client to be able to send greater than 32k query block size.
---
Key: DERBY-1441
URL: http://issues.apache.org/jira/browse/DERBY-1441
Project: Derby
Type: Improvement
Components: Network
Do performance analysis and come up with a good query block size value for the
client to send to the server
---
Key: DERBY-1442
URL:
[
http://issues.apache.org/jira/browse/DERBY-959?page=comments#action_12417367 ]
Sunitha Kambhampati commented on DERBY-959:
---
Discussion happened on this issue on derby-dev. Here is the link to the
discussion that happened on derby-dev
Under Deprecated there is:
A deprecated interface may be removed from the project after four minor
and/or major releases.
http://wiki.apache.org/db-derby/ForwardCompatibility#head-b94fc1d3af5d38a917e2b6c754a8c4213e28f06e
Not sure that really works. With an open source project there could be
Ramin Moazeni wrote:
Hello,
I am a Google Summer of code participant working on the Derby
Migration tool project. The High level design document is posted at
http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument
It's great to see you doing this!
There are 2 approaches
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What happens between September 15 and End of October on the
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
Rick Hillegas wrote:
Daniel John Debrunner wrote:
The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
I apologize for creating confusion here. We'd like Mustang to ship with
a fully functional Derby, which creates
[ http://issues.apache.org/jira/browse/DERBY-1320?page=all ]
Manjula Kutty updated DERBY-1320:
-
Attachment: procedure.java
Test lang/procedure.java fails with ibm1.5 jvm
--
Key: DERBY-1320
Ok, this is very tricky. First, I'd like to make sure we're on the same
page here about Java DB going into the JDK. I think in general the
community thinks it's a good thing for Derby for Java DB to be in the
JDK. It gives us great exposure and distribution. I also think the
community
David Van Couvering wrote:
...
In order for this to work, we need Java DB to be based on an official,
GA-ready release of Derby to be what Sun redistributes in Mustang.
Otherwise databases created in Mustang will be locked in to Java DB.
The problem is that it can't *actually* be GA until
Jean T. Anderson wrote:
David Van Couvering wrote:
...
In order for this to work, we need Java DB to be based on an official,
GA-ready release of Derby to be what Sun redistributes in Mustang.
Otherwise databases created in Mustang will be locked in to Java DB.
The problem is that it can't
Andrew McIntyre wrote:
Call in the lawyers:
From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
has executed, being a JCP Member (they've even got quotes from Geir
prominently featured on their about JCP 2.6 page [2]):
5.B. License to Create Independent
Jean and Dan, you raise good points
(a) what happens if someone downloads this GA-ready but not GA release
of Derby. If for some reason we have to do a respin of the release (see
(b)), how will they later know that it's not actually an official
release of Apache?
(b) is there a
[
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417392 ]
Kathey Marsden commented on DERBY-1434:
---
Wish I could delete the comment but the early closed result set with is issue
is not a valid symptom. This wrong line caused
Andrew McIntyre wrote:
Anyway, what's the trigger for breaching the contract here? If it's
'creation' alone, then rolling that release candidate surely qualifies
as as creation. If it's 'creation and distribution,' well, is posting
the release candidate in a public forum and on a public website
Daniel John Debrunner wrote:
Andrew McIntyre wrote:
Call in the lawyers:
From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
has executed, being a JCP Member (they've even got quotes from Geir
prominently featured on their
that was MUCH clearer than what rick wrote.. thanks
David Van Couvering wrote:
Ok, this is
very tricky. First, I'd like to make sure we're on the same page here
about Java DB going into the JDK. I think in general the community
thinks it's a good thing for Derby for Java DB to be in the JDK.
David Van Couvering wrote:
Andrew McIntyre wrote:
Or maybe ask Geir, since he's VP of Java Community Process for the
Apache Software Foundation, since similar instances may have come up
fairly recently. [3]
Even if we did ask Geir, he's not the last word on it. I'd rather hear
it from
Lance J. Andersen wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.
Are you *sure* you can't *have* a GA version, e.g the bits can't exist
somewhere, as long as they're not officially declared generally
available? If we can't even create the bits, then it
OK, good point, thanks.
David
Daniel John Debrunner wrote:
David Van Couvering wrote:
Andrew McIntyre wrote:
Or maybe ask Geir, since he's VP of Java Community Process for the
Apache Software Foundation, since similar instances may have come up
fairly recently. [3]
Even if we did ask
Hi, Lance. Sorry I had to challenge you publicly on the list, but
I'm really worried that if we're not very careful we are going to paint
ourselves into a corner and we are going to have to fork Derby in order
to do a Java DB release.
I think we need the JCP lawyers (and it sounds like the
That said, it's probably also good to hear from the JCP as well. It
would probably help the ASF gauge what their exposure is and what
approaches they feel comfortable with.
David
David Van Couvering wrote:
OK, good point, thanks.
David
Daniel John Debrunner wrote:
David Van Couvering
David Van Couvering wrote:
Lance J. Andersen wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
final.
Are you *sure* you can't *have* a GA version, e.g the bits can't exist
somewhere, as long as they're not officially declared generally
available? If we can't
Hi,Jean commented on David's post:... In order for this to work, we need Java DB to be based on an official,"GA-ready" release of Derby to be what Sun redistributes in Mustang.Otherwise databases created in Mustang will be "locked in" to Java DB.The problem is that it can't *actually* be GA until
David posted a good summary of the legal catch-22 at [1]. But the
shortest story is:
+ Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
+ Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.
Let's keep this thread confined to the JCP issue Andrew raised that
Jean T. Anderson wrote:
David posted a good summary of the legal catch-22 at [1]. But the
shortest story is:
+ Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
+ Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.
Let's keep this thread confined to
On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
final.
Where does this restriction come from?
Until a spec is final I don't see how you can have a certified compliant
implementation of that spec. It might be as
Jean T. Anderson wrote:
David posted a good summary of the legal catch-22 at [1]. But the
shortest story is:
+ Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
+ Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.
Let's keep this thread confined to the
Daniel John Debrunner wrote:
Jean T. Anderson wrote:
David posted a good summary of the legal catch-22 at [1]. But the
shortest story is:
+ Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
+ Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.
Let's
Brian McCallister wrote:
On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
final.
Where does this restriction come from?
Until a spec is final I don't see how you can have a certified compliant
implementation
Brian McCallister wrote:
If the interfaces happen to exist in a release before the spec is final,
well, cool. Folks using them are at risk of the spec changing at the
last
minute, so I would put bright red warnings around them if they are event
documented before the official release of the
Kathey Marsden wrote:
Brian McCallister wrote:
If the interfaces happen to exist in a release before the spec is final,
well, cool. Folks using them are at risk of the spec changing at the
last
minute, so I would put bright red warnings around them if they are event
documented before
Geir Magnusson Jr wrote:
Daniel John Debrunner wrote:
Jean T. Anderson wrote:
David posted a good summary of the legal catch-22 at [1]. But the
shortest story is:
+ Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
+ Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is
Brian McCallister wrote:
On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
final.
Where does this restriction come from?
Until a spec is final I don't see how you can have a certified compliant
89 matches
Mail list logo
