Re: [PATCH] test harness sed.java readme
On 5/18/05, Myrna van Lunteren [EMAIL PROTECTED] wrote: To check, you want me to: 1. make a separate patch for Sed.java without any formatting. 2. another one for the readme.txt. Actually, no, I've already reviewed the patch and it's fine. It just took me a while, and it would have been easier if there were not so many diffs that were just formatting related. I'll commit what you've already submitted as-is. 3. log a bug for the spaces not working fix that with the readme.txt patch Yes, please. (or I will :-) ) And of course I ran all tests. Should've said so. I suspected as much, but I wanted to make sure. No need to submit a separate patch. andrew
Re: [PATCH] test harness sed.java readme
On 5/16/05, Myrna van Lunteren [EMAIL PROTECTED] wrote: From looking at functionTests/harness/Sed.java after some trouble reported because of directory names, I noticed there was a lot of old - let's call it: - stuff that wasn't needed anymore. So, this patch contains a slightly cleaned up file. Committed, revision 170880. andrew
[jira] Updated: (DERBY-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Andrew Kachalo updated DERBY-297: - Attachment: derby4.jpg http://www.geocities.com/andrew_kachalo/portfolio/derby Submit an entry for the Derby logo contest by uploading it to this issue Key: DERBY-297 URL: http://issues.apache.org/jira/browse/DERBY-297 Project: Derby Type: Task Components: Web Site Reporter: Jean T. Anderson Assignee: Jean T. Anderson Priority: Minor Attachments: derby4.jpg On May 3 Susan Cline posted a note to kick start the Derby logo contest: http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] If you have a logo to submit, please attach it to this issue. (See http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] for the suggestion on using Jira to manage logo submissions.) The assignee will post the attached logos to the Derby web site for easy review. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [PATCH] MacOS X BUILDING.txt
On May 18, 2005, at 3:20 PM, Craig Russell wrote: Thanks. I've incorporated the information from DERBY-1 into the proposed update to the BUILDING.txt, which you will find attached. The patch is based on revision 170836. Thanks for the patch, Craig. I've expanded on your original patch to include some notes on JDK 1.5 and Mac OS X 10.4, so please take a look at my attached edits. This patch has also been merged with other recent edits to BUILDING.txt. If you have no additions or objections, I'll commit this on Friday. andrew macosx-building.diff Description: Binary data
[jira] Commented: (DERBY-276) ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row.
[ http://issues.apache.org/jira/browse/DERBY-276?page=comments#action_65745 ] Bernt M. Johnsen commented on DERBY-276: The functionality of next,previous,first,last,beforeFirst,afterLast,relative and absolute should be aligned with ch. 14.2.2 in the JDBC 3.0 spec. Another issue found: absolute(0) should behave like beforeFirst() ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. Key: DERBY-276 URL: http://issues.apache.org/jira/browse/DERBY-276 Project: Derby Type: Bug Components: JDBC Reporter: Bernt M. Johnsen Assignee: Bernt M. Johnsen Priority: Minor If the cursor is not positioned on a row, calling ResultSet.relative() causes the following exception: Exception in thread main ERROR X0X87: ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getRelativeRow(ScrollInsensitiveResultSet.java:336) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:366) at org.apache.derby.impl.jdbc.EmbedResultSet.relative(EmbedResultSet.java:1840) However, The 1.4.2 Javadoc says: Note: Calling the method relative(1) is identical to calling the method next() and calling the method relative(-1) is identical to calling the method previous(). (This is confirmed by the JDBC 3.0 spec, ch. 14.2.2) Since next() is valid, so should rs.relative(1) (and all other arguments, since a too large value will position the cursor after the last row, and a too low value will position it before the first). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-276) ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row.
[ http://issues.apache.org/jira/browse/DERBY-276?page=all ] Bernt M. Johnsen reassigned DERBY-276: -- Assign To: Bernt M. Johnsen ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. Key: DERBY-276 URL: http://issues.apache.org/jira/browse/DERBY-276 Project: Derby Type: Bug Components: JDBC Reporter: Bernt M. Johnsen Assignee: Bernt M. Johnsen Priority: Minor If the cursor is not positioned on a row, calling ResultSet.relative() causes the following exception: Exception in thread main ERROR X0X87: ResultSet.relative(int row) cannot be called when the cursor is not positioned on a row. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getRelativeRow(ScrollInsensitiveResultSet.java:336) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:366) at org.apache.derby.impl.jdbc.EmbedResultSet.relative(EmbedResultSet.java:1840) However, The 1.4.2 Javadoc says: Note: Calling the method relative(1) is identical to calling the method next() and calling the method relative(-1) is identical to calling the method previous(). (This is confirmed by the JDBC 3.0 spec, ch. 14.2.2) Since next() is valid, so should rs.relative(1) (and all other arguments, since a too large value will position the cursor after the last row, and a too low value will position it before the first). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-220) Javadoc build should include a timestamp and/or the svn revision number in a visible location.
[ http://issues.apache.org/jira/browse/DERBY-220?page=all ] Dyre Tjeldvoll reassigned DERBY-220: Assign To: Dyre Tjeldvoll Javadoc build should include a timestamp and/or the svn revision number in a visible location. -- Key: DERBY-220 URL: http://issues.apache.org/jira/browse/DERBY-220 Project: Derby Type: Improvement Components: Build tools Versions: 10.1.0.0 Reporter: Samuel Andrew McIntyre Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.1.0.0 In order to easily identify when a specific set of javadoc was built, and from what source, it would be useful to include a timestamp and/or the svn revision number at the time the javadoc is built. The footer is an excellent location to place this information, as it is visible on every generated page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Fwd: [PATCH] MacOS X BUILDING.txt
Hi Andrew, The changes look great. It would be nice if this makes it into the 10.1 release! Thanks, Craig Begin forwarded message: From: Andrew McIntyre [EMAIL PROTECTED]> Date: May 19, 2005 8:13:15 AM PDT To: Craig Russell [EMAIL PROTECTED]> Subject: Re: [PATCH] MacOS X BUILDING.txt Hi Craig, Here 'tis: macosx-building.diff Description: Binary data andrew On May 19, 2005, at 7:30 AM, Craig Russell wrote: Hi Andrew, I missed your attached edits. I just looked in the digest (I don't yet have the energy to subscribe to the alias itself ;-) but couldn't find your attachment. Could you send it directly to me? Thanks, Craig From: Andrew McIntyre [EMAIL PROTECTED]> Date: May 19, 2005 1:02:18 AM PDT To: Derby Development derby-dev@db.apache.org> Subject: Re: [PATCH] MacOS X BUILDING.txt On May 18, 2005, at 3:20 PM, Craig Russell wrote: Thanks. I've incorporated the information from DERBY-1 into the proposed update to the BUILDING.txt, which you will find attached. The patch is based on revision 170836. Thanks for the patch, Craig. I've expanded on your original patch to include some notes on JDK 1.5 and Mac OS X 10.4, so please take a look at my attached edits. This patch has also been merged with other recent edits to BUILDING.txt. If you have no additions or objections, I'll commit this on Friday. andrew Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Planning for a 10.1 release
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: [jira] Commented: (DERBY-296) Document
David Van Couvering wrote: I could do this; every time I talk to customers they hammer into me that clear and helpful error messages are key. Users would definitely appreciate your contribution! It would *really* help if I knew which message texts were modified in the doc. Is it limited to the Derby-specific messages with SQLStates starting with X? Unfortunately Jeff is on vacation, will be back June 6 if I remember right. So all I know is what he posted to Jira. Would I submit this as an independent patch to the same JIRA item? Note Or maybe open a sub task and submit a patch to that? My guess is there are additional things to watch out for; for example, updating the tests to reflect the changed messages so derbyall passes. Also, I don't know what gotchas might be out in the locale files -- would be another thing to follow up on. Anything else, derby developers? also that I may find bugs in the messages that would require a redo of the documentation... In my opinion, the docs (including any doc patches submitted) should be changed to match the code. -jean
Question about message token separators
I am looking at Derby-285
Network Client should not print non-ascii token separators in message
when it cannot connect to the server to retrieve the error message
These characters break Jira Export if a Network Client trace is put into
Jira.
Currently the message tokens get sent by the server to the client in the
SQLERRMSG_m field of the SQLXCAXGRP.
The client then calls a stored procedure SYSIBM.SQLCAMESSAGE with the
SQLERRMSG_m value as a parameter to get the full localized message. A
non ascii separator is used as a token separator and used by the stored
procedure to separate the tokens.
In the server (DRDAConnThread) we have these separators.
byte[] sep = {20};// use it as separator of sqlerrmc
tokens
byte[] errSep = {20, 20, 20}; // mark between exceptions
String separator = new String(;);
String errSeparator = new String(errSep);
The client normally just sends the full string back to the server, but
does have code to split up the tokens if it can't retrieve the message.
This code expects a byte value of -1 as a separator.
org.apache.derby.client.am.SQLca.java:
// non-delimiter - continue to write into buffer
if (tokenBytes[index] != -1) // -1 is the delimiter '\xFF'
Short term options include:
1) Send an ascii separator of some sort. (Is there some safe value
that would not be in the messages?)
2) Change the client to expect what the server is sending.
3) Change the server to send what the client is expecting.
I'm leaning toward 2 so as not to impose any risk for backward
compatibility or odbc or whatever. On the other hand I always thought
those separator values in the server were a bit weird. Does anyone have
any thoughts on this?
Kathey
IRC channel
Given the email delays, I opened an IRC channel for Derby discussion: IRC://irc.freenode.net/#derby It will at least allow communication with a 6 hour lag time :-( -- Jeremy
Re: IRC channel
Jeremy Boynes wrote: Given the email delays, I opened an IRC channel for Derby discussion: IRC://irc.freenode.net/#derby It will at least allow communication with a 6 hour lag time :-( -- Jeremy Ken also set one up, I've no-idea on if it still exists or has been used. Dan. Ken wrote: there's an #apache-derby irc channel on the freenode network for people wanting to have real-time discussions. just remember that any discussions that lead to action on the code need to be summarised on the list here, and any necessary go/no-go decision needs to be made here too. (for archival and audit purposes.) - -- #ken P-)} http://mail-archives.apache.org/mod_mbox/db-derby-dev/200409.mbox/[EMAIL PROTECTED]
Re: [PATCH] MacOS X BUILDING.txt
On May 19, 2005, at 9:45 AM, Craig Russell wrote: The changes look great. It would be nice if this makes it into the 10.1 release! Committed, revision 171003. andrew
Re: [jira] Commented: (DERBY-296) Document
Here's a text file that might help...it litst all the
messages with changes, and then the old and the new
version.
By the way, I am currently away on vacation, and my
access to email is limited. Just wanted to explain
why you might not get responses from me on various
items of discussion from time to time. I may not be
able to get to topics that people address to me until
I get back in a few weeks, but I will do my best.
--- David Van Couvering [EMAIL PROTECTED]
wrote:
I could do this; every time I talk to customers they
hammer into me that
clear and helpful error messages are key.
It would *really* help if I knew which message texts
were modified in
the doc. Is it limited to the Derby-specific
messages with SQLStates
starting with X?
Would I submit this as an independent patch to the
same JIRA item? Note
also that I may find bugs in the messages that
would require a redo of
the documentation...
David
Jean T. Anderson wrote:
David Van Couvering wrote:
I would agree... I think the right thing to do
would be to fix the code.
David
is that an offer? :-)
-jean
Jean T. Anderson (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717
]
Jean T. Anderson commented on DERBY-296:
Regarding this:
During my work, I discovered that many of the
messages could use
some spellchecking, grammar checking, etc.
Rather than document them
this way, I corrected them. At some point a
separate JIRA issue
should be made, and someone should undertake
the task of fixing the
actual message strings to reflect the correct
grammar, spelling,
punctuation, etc. used in this document.
I'm concerned users might be confused if the
error message an
application spits out does not exactly match the
error message string
documented in the Reference Manual.
I think this work shouldn't be committed until
doc matches code
(whether it involves changing the messages in
this patch or modifying
the code to match these).
Document
Key: DERBY-296
URL:
http://issues.apache.org/jira/browse/DERBY-296
Project: Derby
Type: Task
Components: Documentation
Environment: all
Reporter: Jeff Levitt
Assignee: Jeff Levitt
Priority: Minor
Attachments: derby296.zip
I've spent some time compiling a list of error
messages for Derby,
to expand on the error messages section
currently in the Reference
Manual. I am about ready to submit a candidate
patch, and I am
opening up a JIRA issue to contain it.
Original: 0100E|XX Attepmt to return too many result sets
Changed to: XX Attempt to return too many result sets.
Original: 22014|The start positon for LOCATE is invalid; it must be a positive
integer. The index to start the search from is '{2}'. The string to search
for is '{0}'. The string to search from is '{1}'.
Changed to: 22014|The start position for LOCATE is invalid; it must be a
positive integer. The index to start the search from is '{2}'. The string to
search for is
'{0}'. The string to search from is '{1}'.
Original: 22019|Invalid escape sequence, '{0}'. The escape string must be
exactly one character. It can not be a null or more than one character.
Changed to: 22019|Invalid escape sequence, '{0}'. The escape string must be
exactly one character.It cannot be a null or more than one character.
Original: 25501|Unable to set the connection read only property in an active
transaction.
Changed to: 25501|Unable to set the connection read-only property in an active
transaction.
Original: 40XD1|Container was opened in read only mode
Changed to: 40XD1|Container was opened in read-only mode.
Original: 40XD2|Container {0} cannot be opened, either it has been dropped or
is non-existant
Changed to: 40XD2| Container {0} cannot be opened; it either has been dropped
or does not exist.
Original: 40XT4|An attempt was made to close a transaction that was still
active, transaction has been aborted.
Changed to: 40XT4|An attempt was made to close a transaction that was still
active. The transaction has been aborted.
Original: 40XT6|Database is in quiescent state, cannot activate transaction.
Please wait for a moment till it exits the quiescent state.
Changed to: 40XT6|Database is inactive and cannot activate the transaction.
Please wait for
a moment until it exits the inactive state.
Original:40001|A lock could not be obtained due to a deadlock, cycle of locks
waiters is:
{0}The selected victim is XID : {1}
Changed to: A lock could not be obtained due to a deadlock, cycle of locks and
waiters
is: {0} The selected victim is XID :{1}.
Original: 42601|ALTER TABLE statement can not add an IDENTITY column to a
table.
Changed to: 42601|ALTER TABLE statement cannot add an IDENTITY column to a
table.
Re: Planning for a 10.1 release
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: [PATCH] Timestamp Arithmetic
I thought that I read somewhere that TIMESTAMPADD was supposed to take
the integer part of its count argument. I think that I was wrong. The
Microsoft ODBC documentation says Arguments denoted as /integer_exp/
can be the name of a column, the result of another scalar function, or a
/numeric-literal/, where the underlying data type can be represented as
SQL_TINYINT, SQL_SMALLINT, SQL_INTEGER, or SQL_BIGINT. I will change
the timestampAddBind method to check that the count argument is an
integer type.
Jack
Satheesh Bandaram wrote:
TimestampAdd seems to allow adding non-integer intervals, but the
behavior doesn't seem right. Either the result should be 10:10:20.9
or the statement should error. Though JDBC documenation is not very
clear, I thought the count intervals need to be an integer?
ij values {fn timestampadd(SQL_TSI_SECOND, 10.9, time('10:10:10'))};
1
--
2005-05-18 10:10:20.0
If we only allow integers for count, then the following needs to change:
+if( ! bindParameter( rightOperand, Types.INTEGER))
+{
+if( ! rightOperand.getTypeId().isNumericTypeId())
+throw
StandardException.newException(SQLState.LANG_INVALID_FUNCTION_ARG_TYPE,
+
rightOperand.getTypeId().getSQLTypeName(),
+
ReuseFactory.getInteger(2),
+ operator);
+}
Satheesh
I postpone modification to dblook.(Re: Patch again again for DERBY-167.)
Hello.
I decide to postpone modification of dblook.
Modification itself is not difficult.
However , it is needed to know all about SYSTEM table , to check
modification was correctly done.
It is a little hard for me to understand all about SYSTEM table right now.
//This may be suitable for my next task ...
Best regards.
/*
Tomohito Nakayama
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
- Original Message -
From: TomohitoNakayama [EMAIL PROTECTED]
To: Derby Development derby-dev@db.apache.org
Sent: Wednesday, May 18, 2005 11:36 PM
Subject: Re: Patch again again for DERBY-167.
Hello.
Daniel John Debrunner wrote:
1st:
The Derby dblook utility will have to be modified to account for the
BY DEFAULT keyword--right now, it generates all autoincrement
columns using the ALWAYS keyword. See
org/apache/derby/impl/tools/dblook/DB_Table.java, in the
reinsateAutoIncrement method. Luckily, this change should be fairly
easy given the changes in your patch.
I see.
I will modify dblook.
Thank you for your notifying :D
The dblook changes could be a separate patch. Incremental development
is a good process, rather than requiring all the related changes to
be in one huge patch.
Well
I just have started modification of dblook.
Then I will include it.
But if encountered some problem , I will postpone it for other task.
if (defaultInfo != null ! colDesc.isAutoincrement())
it would be good to add some descriptive comment. The issue here is that
the test is two negative conditions 'anded ()' together. Somewhat hard
for humans (well at least me) to understand quickly. A comment is also
useful for the original coder to help them ensure they have the correct
condition.
Well
This condition is surely difficult.
Comment will be needed .
I will add.
Sometimes comment can be barrier for reading code.
Therefore, I hesitate to write comment.
BITS_MASK_IS_DEFAULTVALUE_AUTOINC should be 'final' if it is intended to
be a constant.
In DefaultInfoImpl the calculating of definitionBits and
isDefaultValueAutoinc using those static methods seems too complex. If
there are ever a few more types to calculate we end up with a lot of
code to deal with it. Why not just have a single instance field
representing the type (matching your defintion bits), remove
isDefaultValueAutoinc field. Then the read/writeExternal methods just
write the type directly, and the isDefaultValueAutoinc method is
something like
+ public boolean isDefaultValueAutoinc(){
+ return (type BITS_MASK_IS_DEFAULTVALUE_AUTOINC) != 0;
+ }
I hesitated calculating each time calling isDefaultValueAutoinc() method.
Well But its very small price.
Price of calculating each time will correspond to simple code.
I will modify it.
Best regards.
/*
Tomohito Nakayama
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
- Original Message -
From: Daniel John Debrunner [EMAIL PROTECTED]
To: Derby Development derby-dev@db.apache.org
Sent: Wednesday, May 18, 2005 10:22 PM
Subject: Re: Patch again again for DERBY-167.
TomohitoNakayama wrote:
Hello.
1st:
The Derby dblook utility will have to be modified to account for the
BY DEFAULT keyword--right now, it generates all autoincrement
columns using the ALWAYS keyword. See
org/apache/derby/impl/tools/dblook/DB_Table.java, in the
reinsateAutoIncrement method. Luckily, this change should be fairly
easy given the changes in your patch.
I see.
I will modify dblook.
Thank you for your notifying :D
The dblook changes could be a separate patch. Incremental development
is a good process, rather than requiring all the related changes to
be in one huge patch.
2nd:
Second (minor):
I noticed that in DefaultInfoImpl.java, the two new methods
(getDefinitionBitsValue and calcIsDefaultValueAutoinc) are declared as
static--is there a reason for that? I made them non-static and
everything compiled, so I'm just wondering if this was intentional?
Yes. That was intentional.
I prefer static method because it have narrower scope than instance
method.
I agree, static methods are the correct type here.
I would encourage you (and anyone else) to keep any description (or
modified version of it) from the original patch e-mail in newer e-mails
with modified patches. This makes it easier for the committers to
understand and track patches. E.g. you last Derby-167 patch just had the
patch attached, you should keep any description from the first e-mail
with the patch. Another reason is that the description may have changed
due to comments etc.
In general the patch looks good, thanks for making changes for my
previous feedback.
Some minor comments on the patch:
In ResultSetNode and ColumnDefintionNode for this line you changed
if (defaultInfo != null ! colDesc.isAutoincrement())
it would be good to add some descriptive comment. The issue here is that
the
Re: [jira] Commented: (DERBY-296) Document
Great, thanks Jeff!
David
Jeff Levitt wrote:
Here's a text file that might help...it litst all the
messages with changes, and then the old and the new
version.
By the way, I am currently away on vacation, and my
access to email is limited. Just wanted to explain
why you might not get responses from me on various
items of discussion from time to time. I may not be
able to get to topics that people address to me until
I get back in a few weeks, but I will do my best.
--- David Van Couvering [EMAIL PROTECTED]
wrote:
I could do this; every time I talk to customers they
hammer into me that
clear and helpful error messages are key.
It would *really* help if I knew which message texts
were modified in
the doc. Is it limited to the Derby-specific
messages with SQLStates
starting with X?
Would I submit this as an independent patch to the
same JIRA item? Note
also that I may find bugs in the messages that
would require a redo of
the documentation...
David
Jean T. Anderson wrote:
David Van Couvering wrote:
I would agree... I think the right thing to do
would be to fix the code.
David
is that an offer? :-)
-jean
Jean T. Anderson (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717
]
Jean T. Anderson commented on DERBY-296:
Regarding this:
During my work, I discovered that many of the
messages could use
some spellchecking, grammar checking, etc.
Rather than document them
this way, I corrected them. At some point a
separate JIRA issue
should be made, and someone should undertake
the task of fixing the
actual message strings to reflect the correct
grammar, spelling,
punctuation, etc. used in this document.
I'm concerned users might be confused if the
error message an
application spits out does not exactly match the
error message string
documented in the Reference Manual.
I think this work shouldn't be committed until
doc matches code
(whether it involves changing the messages in
this patch or modifying
the code to match these).
Document
Key: DERBY-296
URL:
http://issues.apache.org/jira/browse/DERBY-296
Project: Derby
Type: Task
Components: Documentation
Environment: all
Reporter: Jeff Levitt
Assignee: Jeff Levitt
Priority: Minor
Attachments: derby296.zip
I've spent some time compiling a list of error
messages for Derby,
to expand on the error messages section
currently in the Reference
Manual. I am about ready to submit a candidate
patch, and I am
opening up a JIRA issue to contain it.
Original: 0100E|XX Attepmt to return too many result sets
Changed to: XX Attempt to return too many result sets.
Original: 22014|The start positon for LOCATE is invalid; it must be a positive integer. The index to start the search from is '{2}'. The string to search for is '{0}'. The string to search from is '{1}'.
Changed to: 22014|The start position for LOCATE is invalid; it must be a positive integer. The index to start the search from is '{2}'. The string to search for is
'{0}'. The string to search from is '{1}'.
Original: 22019|Invalid escape sequence, '{0}'. The escape string must be exactly one character. It can not be a null or more than one character.
Changed to: 22019|Invalid escape sequence, '{0}'. The escape string must be exactly one character.It cannot be a null or more than one character.
Original: 25501|Unable to set the connection read only property in an active transaction.
Changed to: 25501|Unable to set the connection read-only property in an active transaction.
Original: 40XD1|Container was opened in read only mode
Changed to: 40XD1|Container was opened in read-only mode.
Original: 40XD2|Container {0} cannot be opened, either it has been dropped or
is non-existant
Changed to: 40XD2| Container {0} cannot be opened; it either has been dropped
or does not exist.
Original: 40XT4|An attempt was made to close a transaction that was still
active, transaction has been aborted.
Changed to: 40XT4|An attempt was made to close a transaction that was still
active. The transaction has been aborted.
Original: 40XT6|Database is in quiescent state, cannot activate transaction. Please wait for a moment till it exits the quiescent state.
Changed to: 40XT6|Database is inactive and cannot activate the transaction. Please wait for
a moment until it exits the inactive state.
Original:40001|A lock could not be obtained due to a deadlock, cycle of locks waiters is:
{0}The selected victim is XID : {1}
Changed to: A lock could not be obtained due to a deadlock, cycle of locks and waiters
is: {0} The selected victim is XID :{1}.
Original: 42601|ALTER TABLE statement can not add an IDENTITY column to a table.
Changed to: 42601|ALTER TABLE statement cannot add an IDENTITY column to a table.
Original: 42610|All the arguments to the COALESC/VALUE function can not
Question with binding...
Hi,
This message is asking for help debugging some specific changes that I've
written for Derby, so if you're not interested in my own personal coding
problems, feel free to stop reading now ;)
I'm trying to add language support to Derby so that it allows aggregate
functions to be used in the WHERE iff they are a) in a subquery of a HAVING
clause and b) they correlate to an outer query block.
As a first step toward part a, I made what seem to me like reasonable changes
to the SelectNode class so that Derby will allow aggregates in the WHERE of a
HAVING subquery. At a high level, what my changes do (or at least, what I want
them to do) is as follows.
Assume I have a query of the form:
OUTER_SELECT GROUP_BY having outer_col_a = SUBSELECT
and SUBSELECT is something like
select x from t1 where min(outer_col_b) 0
and outer_col_b is a column that is both in the OUTER_SELECT list and in the
GROUP_BY list. That said, the changes I've made would rewrite the SUBSELECT
to represent the following:
select x, min(outer_col_b) SQLCol1 from t1 where SQLCol1 0
(Note that this is what the rewritten query _represents_--this in itself isn't
necessary valid SQL).
With this new query I bind SQLCol1 without any problems, but at execution time,
the result is an NPE from within the generated code for the query. I poked
through the derby.log file and rewrote the query in a bunch of different ways,
and I now _think_ problem is that the DataValueDescriptor for SQLCol1 in the
WHERE clause is null at row retrieval time, and that's causing the NPE.
Are there any language experts out there who can look at the attached patch and
offer input as to why the DataValueDescriptor for the aggregate result column
would end up null on a call to retrieve the results? I've made sure that the
aggregate is bound at compile time (and I've tried binding it in lots of
different ways) but it looks like I'm missing something somewhere.
I've attached a small patch with minimal changes to reproduce the problem. I've
re-written this patch too many times to count, some times in ways that were very
simple (like the one attached to this patch) and some times in ways that were
significantly more complex--but in all cases, I keep coming back to this NPE
problem.
Using the attached patch, the NPE can be reproduced with either of the following
two scenarios:
1) A realistic scenario that actually has some meaning (and thus is more
complicated);
ij create table team (teamid int not null primary key, budget double);
ij create table players (id int not null unique, teamid int references team,
salary double);
ij insert into team values (1, 100), (2, 200), (3, 300), (4, 400);
ij insert into players values (1, 1, 50), (2, 1, 75), (3, 1, 60);
3 rows inserted/updated/deleted
ij insert into players values (4, 2, 10), (5, 2, 25), (6, 2, 30);
3 rows inserted/updated/deleted
ij insert into players values (7, 3, 25), (8, 3, 30), (9, 3, 20), (10, 3, 45);
-- Now, look for all players such that: 1) the player is on a team with an
average salary that is less than half of the team's budget, AND 2) the player is
the lowest-paid player on his/her team, AND 3) the player is making less than
20 (i.e. maybe these player should get a raise! ;). In such cases, retrieve
the player's team and his/her salary.
ij select t.teamid,p.salary from team t, players p where (p.teamid = t.teamid)
group by t.teamid,p.salary having avg(p.salary) (select (t2.budget / 2) from
team t2 where t2.teamid = t.teamid and 20 min(p.salary));
2) A simpler query that doesn't make any logical sense but still reproduces the
problem:
ij create table t1 (i int);
ij create table t2 (j int);
ij create table t3 (k int);
ij insert into t1 values 2, 4, 6;
ij insert into t2 values 1, 3, 7;
ij insert into t3 values 1, 2, 3, 4, 5;
ij select j,k from t2 t2_alias, t3 t3_alias group by j,k having j (select
min(2) from t1 where min(t3_alias.k) 0);
It's the derby.log file for this second query that makes me think the
DataValueDescriptor is null and thus the NPE.
Many thanks to any who has the time to point out what I'm missing,
Army
Index: java/engine/org/apache/derby/impl/sql/compile/SelectNode.java
===
--- java/engine/org/apache/derby/impl/sql/compile/SelectNode.java
(revision 170947)
+++ java/engine/org/apache/derby/impl/sql/compile/SelectNode.java
(working copy)
@@ -519,10 +519,11 @@
** in the WHERE clause at all.
** Note: a similar check is made in JoinNode.
*/
- if ((whereAggregates.size() 0)
- !generatedForHavingClause)
+ if (whereAggregates.size() 0)
{
- throw
StandardException.newException(SQLState.LANG_NO_AGGREGATES_IN_WHERE_CLAUSE);
+ if
Re: [PATCH] increasinng the possible log file id's from 2^22 -1 to 2^33 -1 (derby-101)
I just realized , this patch actaully break's hard upgrade also, if log needs to be replayed. Becuase I extract the log file number and log file postion from the instant that is on disk , differently after my change. If any one else on the list is testing upgrade is hitting this problem, please let me know. I can post a patch to backout the portion that cause upgrade issues. Thanks -suresht Mike Matrigali wrote: I am looking at committing this. The changes look good to me, but I believe there are upgrade issues to handle. For a hard upgrade either new or old databases are fine. For a soft upgrade I think there is a problem if the db generates enough log files to start using the new bits, and then the software is reverted to before the fix. Seems like using the bits needs to be somehow only enabled for hard upgrade. It would be best if it was controlled just by hard upgrade, but if that is not possible then just doing it for databases created since this version would also work - but still leave problems with old hard upgraded databases. I have reviewed the code and am running tests. I plan on committing this part of the fix and let you address upgrade issues with a follow on patch. Suresh Thalamati wrote:
[jira] Assigned: (DERBY-266) test tools/dblook_test.java fails if run in a directory having *derby/* in its path
[ http://issues.apache.org/jira/browse/DERBY-266?page=all ] Myrna van Lunteren reassigned DERBY-266: Assign To: Myrna van Lunteren test tools/dblook_test.java fails if run in a directory having *derby/* in its path - Key: DERBY-266 URL: http://issues.apache.org/jira/browse/DERBY-266 Project: Derby Type: Bug Components: Test Versions: 10.1.0.0 Reporter: Dag H. Wanvik Assignee: Myrna van Lunteren Priority: Minor Fix For: 10.1.0.0 SYMPTOM: The test tools/dblook_test will fail. The diff looks similar to this: *** Start: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:37 *** 4861d4860 java.io.FileNotFoundException: filePath Test Failed. *** End: dblook_test jdk1.4.2_02 derbyall:derbytools 2005-05-06 22:37:53 *** cf mail thread: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/[EMAIL PROTECTED] ANALYSIS: The problem lies with the sed functionality in the test harness, which delete certain lines before comparing with the master file. Sed.java in the harness removes lines containing *derby/* in the path, viz: deleteLines.addElement(^.*derby/.*\\.*(.*\\).*$); deleteLines.addElement(^.*derby/.*\\(.*\\).*$); so if your tests are running in a directory containing this pattern, a line too much is deleted from dblook_test.tmp, thereby giving a comparison failure like you describe. I don't know the reason for this deletion yet, so I can't say how to fix it, but the work-around is obvious: Run test in a directory whose name does not contain this pattern ;-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Jean T. Anderson updated DERBY-297: --- Description: On May 3 Susan Cline posted a note to kick start the Derby logo contest: http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] If you have a logo to submit, please attach it to this issue. (See http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] for the suggestion on using Jira to manage logo submissions.) The assignee will update the index to images below: Attachment FileSubmitter -- --- --- 1 derby4.jpg Andrew Kachalo was: On May 3 Susan Cline posted a note to kick start the Derby logo contest: http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] If you have a logo to submit, please attach it to this issue. (See http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] for the suggestion on using Jira to manage logo submissions.) The assignee will post the attached logos to the Derby web site for easy review. Submit an entry for the Derby logo contest by uploading it to this issue Key: DERBY-297 URL: http://issues.apache.org/jira/browse/DERBY-297 Project: Derby Type: Task Components: Web Site Reporter: Jean T. Anderson Assignee: Jean T. Anderson Priority: Minor Attachments: derby4.jpg On May 3 Susan Cline posted a note to kick start the Derby logo contest: http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] If you have a logo to submit, please attach it to this issue. (See http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] for the suggestion on using Jira to manage logo submissions.) The assignee will update the index to images below: Attachment FileSubmitter -- --- --- 1 derby4.jpg Andrew Kachalo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-302) Takes over 3 minutes to insert a 500kb String into CLOB
Takes over 3 minutes to insert a 500kb String into CLOB
---
Key: DERBY-302
URL: http://issues.apache.org/jira/browse/DERBY-302
Project: Derby
Type: Bug
Components: SQL
Environment: Windows XP Professional, Dell Pentium IV
Reporter: Glenn Orbon
I downloaded a Cloudescape Version 10 from here
http://www-106.ibm.com/developerworks/db2/library/techarticle/dm-0408cline/index.html.
Not sure exactly which version of 10 this is.
Would like to store up to a 10MB XML string in a CLOB. However, I noticed it
took over 3 minutes to insert a 500kb string. I am using the PreparedStatement
to get around the 37kb limitation encountered in a previous issue. It takes
less than 2 seconds to insert a 500kb string into a CLOB in mySQl.
Here the snippet:
FileReader fr = new FileReader (sample.txt);
BufferedReader br = new BufferedReader(fr);
String record = null;
try {
while ( (record=br.readLine()) != null ) {
bufferStr.append( record );
}
} catch (IOException e) {
//
// put your error-handling code here
//
System.out.println(Error reading file);
}
System.out.println(Size of inputStr: +bufferStr.length() );
PreparedStatement ps = mm.connection.prepareStatement(INSERT into
documents VALUES (?,?) );
ps.setInt(1, 13 );
StringReader reader1 = new StringReader(bufferStr.toString());
ps.setCharacterStream(2, reader1, bufferStr.length());
System.out.println(Uploading string);
ps.execute();
System.out.println(Done uploading string...);
mm.connection.commit();
Thanks for your the help,
Glenn O.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-266) test tools/dblook_test.java fails if run in a directory having *derby/* in its path
Hi, MvL( == Myrna van Lunteren (JIRA) derby-dev@db.apache.org wrote: MvL( I also ran derbyall like this (i.e. lines removed, jdk142 on MvL( windows) from a directory which had 'derby' in it, and all test MvL( passed. If reporter could verify this fixes the reported MvL( problem, that would be valuable. I will run it here, Myrna! Thanks, Dag
[jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
[ http://issues.apache.org/jira/browse/DERBY-243?page=all ] David Van Couvering updated DERBY-243: -- Comment: was deleted connection toString should uniquely identify the connection --- Key: DERBY-243 URL: http://issues.apache.org/jira/browse/DERBY-243 Project: Derby Type: Improvement Components: JDBC Reporter: Kathey Marsden Assignee: David Van Couvering Priority: Trivial Fix For: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.0.0 Attachments: DERBY-243.diff The toString() on the Derby connection doesn't print unique information. for example System.out.println(conn) prints: EmbedConnection in the case of derby embedded It would be great if the toString() method for connections could be used to differentiate one connection from another. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-243) connection toString should uniquely identify the connection
[ http://issues.apache.org/jira/browse/DERBY-243?page=comments#action_65821 ] David Van Couvering commented on DERBY-243: --- In response to Kathey's request, I am providing information on the semantics for providing a unique string representation for a connection. First, it is important to identify three major types of connections in Derby: POOLED CONNECTIONS Pooled Connections are a subtype of javax.sql.PooledConnection. They represent a connection stored on a pool. References to PooledConnections are never directly visible to application code. They are used by implementors of connection pools so that management of pooled connections can be standardized across JDBC driver providers. PROXY CONNECTIONS Proxy connections are a class of connections that, although they implement the java.sql.Connection interface, don't directly implement the methods of java.sql.Connection. Instead, they act as a proxy to an underlying physical connection, and allow containers to inject container logic when key connectoin lifecycle events occur. These are also sometimes called logical connections or brokered connections. PHYSICAL CONNECTIONS These are the connection classes that do the heavy lifting of actually implementing the methods on java.sql.Connection. They are the underlying physical connections wrapped by proxy connections. CONNECTION STRING SEMANTICS With these definitions in place, here are the semantics of connection strings: - When a physical connection is created, it is assigned a unique UUID that is unchanged for the lifetime of the connection. - When an application calls Connection.toString(), it gets the string Connection_UUID of the underlying physical connection, regardless of where the application has a reference to the physical connection itself a reference to a proxy connection (aka brokered connection) that wraps the physical connection. - A pooled connection is assigned a separate UUID from a physical connection. When a container calls PooledConnection.toString(), it gets the string PooledConnection_UUID. This is useful for developers implementing connection pools when they are trying to debug pooled connections connection toString should uniquely identify the connection --- Key: DERBY-243 URL: http://issues.apache.org/jira/browse/DERBY-243 Project: Derby Type: Improvement Components: JDBC Reporter: Kathey Marsden Assignee: David Van Couvering Priority: Trivial Fix For: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.0.0 Attachments: DERBY-243.diff The toString() on the Derby connection doesn't print unique information. for example System.out.println(conn) prints: EmbedConnection in the case of derby embedded It would be great if the toString() method for connections could be used to differentiate one connection from another. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-296) Document
David. If you are planning on doing this and making a pass throughout the code to make sure the correct SQLState is set correctly (not just correcting the message property files), it might be worthwhile to add some type of marker comment in places where the code will need to be changed for JDBC 4 in order to bring the SQLExceptions being thrown in line with the changes for the new SQLExceptions based on the SQL state class values. By at least having an easy to find comment, it will make it easier to go back and do the retrofit. Of course this only makes sense if you are going to make a pass through the entire derby codeline for this adventure. just a thought if you are looking to have some more fun 8-) David Van Couvering wrote: I could do this; every time I talk to customers they hammer into me that clear and helpful error messages are key. It would *really* help if I knew which message texts were modified in the doc. Is it limited to the Derby-specific messages with SQLStates starting with X? Would I submit this as an independent patch to the same JIRA item? Note also that I may find bugs in the messages that would require a redo of the documentation... David Jean T. Anderson wrote: David Van Couvering wrote: I would agree... I think the right thing to do would be to fix the code. David is that an offer? :-) -jean Jean T. Anderson (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717 ] Jean T. Anderson commented on DERBY-296: Regarding this: During my work, I discovered that many of the messages could use some spellchecking, grammar checking, etc. Rather than document them this way, I corrected them. At some point a separate JIRA issue should be made, and someone should undertake the task of fixing the actual message strings to reflect the correct grammar, spelling, punctuation, etc. used in this document. I'm concerned users might be confused if the error message an application spits out does not exactly match the error message string documented in the Reference Manual. I think this work shouldn't be committed until doc matches code (whether it involves changing the messages in this patch or modifying the code to match these). Document Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Attachments: derby296.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it.
