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 TomohitoNakayama <to...@basil.ocn.ne.jp> on 2005/05/26 14:09:57 UTC
DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Hello.
I have just done DERBY-308.
I uploaded patch just for reviewing.
Through testing of DERBY-308 , I found one problem in previous DERBY-167.
eol was missed in
java/testing/org/apache/derbyTesting/functionTests/master/ieptests.out ....
Then, test of tools/ieptests.sql was failed.
Thinking this phenomena was not found in testing in DERBY-167,
the bug seems to be made in making patch of DERBY-167.
I will post the bug to JIRA.
Maybe trouble of subversion...
There may be trouble in handling last line in "svn diff"...
I have upgraded subversion to 1.2.0. for care....
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Tomohito Nakayama (JIRA)" <de...@db.apache.org>
To: <to...@basil.ocn.ne.jp>
Sent: Thursday, May 26, 2005 8:49 PM
Subject: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY
DEFAULT AS IDENTITY"
> [ http://issues.apache.org/jira/browse/DERBY-308?page=all ]
>
> Tomohito Nakayama updated DERBY-308:
> ------------------------------------
>
> Attachment: DERBY-308.patch
>
> There results changes of records in systemm tables ,SYSCOLUMNS/
> SYSCONGLOMERATE/ SYSTABLES ,
> generated to
> java/testing/org/apache/derbyTesting/functionTests/master/dblook_test.out
>
>
>> Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"
>> -----------------------------------------------------------
>>
>> Key: DERBY-308
>> URL: http://issues.apache.org/jira/browse/DERBY-308
>> Project: Derby
>> Type: Sub-task
>> Reporter: Tomohito Nakayama
>> Assignee: Tomohito Nakayama
>> Attachments: DERBY-308.patch
>>
>> The Derby "dblook" utility needs to support "GENERATED BY DEFAULT AS
>> IDENTITY".
>> This issue was notified in next mail.
>> http://article.gmane.org/gmane.comp.apache.db.derby.devel/4096
>
> --
> 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
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.17 - Release Date: 2005/05/25
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.17 - Release Date: 2005/05/25
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308)
Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Hi Tomohito,
I found the problem with ieptests and fixed the test master output
already. The test should pass now.
Also, I found you forgot to update ieptests.out for DerbyNet and
DerbyNetClient frameworks. That means the test would have file under
those two frameworks too. I updated those also for you.
When I update a master file, I usually find all other master files with
same name. (At the functionTests/master location: find . -name
'ipetests.out' -print) If there are multiple master files (in
subdirectories) I update all of them too. This has been causing test
failures for a number of patches submitted recently.
Satheesh
TomohitoNakayama wrote:
> Hello.
>
> I have just done DERBY-308.
> I uploaded patch just for reviewing.
>
>
> Through testing of DERBY-308 , I found one problem in previous DERBY-167.
> eol was missed in
> java/testing/org/apache/derbyTesting/functionTests/master/ieptests.out
> ....
> Then, test of tools/ieptests.sql was failed.
>
> Thinking this phenomena was not found in testing in DERBY-167,
> the bug seems to be made in making patch of DERBY-167.
>
> I will post the bug to JIRA.
>
> Maybe trouble of subversion...
> There may be trouble in handling last line in "svn diff"...
>
> I have upgraded subversion to 1.2.0. for care....
>
>
> Best regards.
>
>
> /*
>
> Tomohito Nakayama
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Tomohito Nakayama (JIRA)"
> <de...@db.apache.org>
> To: <to...@basil.ocn.ne.jp>
> Sent: Thursday, May 26, 2005 8:49 PM
> Subject: [jira] Updated: (DERBY-308) Modify dblook to support
> "GENERATED BY DEFAULT AS IDENTITY"
>
>
>> [ http://issues.apache.org/jira/browse/DERBY-308?page=all ]
>>
>> Tomohito Nakayama updated DERBY-308:
>> ------------------------------------
>>
>> Attachment: DERBY-308.patch
>>
>> There results changes of records in systemm tables ,SYSCOLUMNS/
>> SYSCONGLOMERATE/ SYSTABLES ,
>> generated to
>> java/testing/org/apache/derbyTesting/functionTests/master/dblook_test.out
>>
>>
>>
>>> Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"
>>> -----------------------------------------------------------
>>>
>>> Key: DERBY-308
>>> URL: http://issues.apache.org/jira/browse/DERBY-308
>>> Project: Derby
>>> Type: Sub-task
>>> Reporter: Tomohito Nakayama
>>> Assignee: Tomohito Nakayama
>>> Attachments: DERBY-308.patch
>>>
>>> The Derby "dblook" utility needs to support "GENERATED BY DEFAULT AS
>>> IDENTITY".
>>> This issue was notified in next mail.
>>> http://article.gmane.org/gmane.comp.apache.db.derby.devel/4096
>>
>>
>> --
>> 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
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.322 / Virus Database: 266.11.17 - Release Date: 2005/05/25
>>
>>
>
>
>
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308)
Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by Army <qo...@sbcglobal.net>.
Army wrote:
> TomohitoNakayama wrote:
>> I have just done DERBY-308.
>> I uploaded patch just for reviewing.
[snip]
> when I myself
> tried to run dblook_test_net against the server, I got a protocol
> exception with the "GENERATED BY DEFAULT" column.
[snip]
> I will file a JIRA entry for the protocol problem I mentioned
> above.
Filed as DERBY-318. As I say in the description, I'm not sure if this is a
problem with the GENERATED BY DEFAULT feature itself, or with Network Server...
Army
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308)
Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
No problem. :-) I am guilty as well, for not catching missing master
file updates. There were two other patches that missed updating all
master files, around the same time.
All the discussions were to highlight areas typically missed by new
contributors.
Satheesh
TomohitoNakayama wrote:
> Hello.
>
> Reading series of other mail "Running derbyall before submitting
> patches",
> I'm very sorry for DERBY-318....
>
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308)
Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Sounds great! I think it is important to close both these bugs before
the 10.1 release. Post any questions you may have.
Satheesh
TomohitoNakayama wrote:
> Hello.
>
> Reading series of other mail "Running derbyall before submitting
> patches",
> I'm very sorry for DERBY-318....
>
> If possible , I want to work for DERBY-318 before DERBY-308 ....
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Army" <qo...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Friday, May 27, 2005 1:56 AM
> Subject: Re: DERBY-308 just be done and .... (Re: [jira] Updated:
> (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
>
>
>> TomohitoNakayama wrote:
>>
>>> Hello.
>>>
>>> I have just done DERBY-308.
>>> I uploaded patch just for reviewing.
>>
>>
>> Hi Tomohito,
>>
>> Thanks for looking at this so quickly. A couple of comments on the
>> patch:
>>
>> First and most importanly:
>>
>> It looks like you have run the dblook_test for embedded mode and have
>> updated the master, which is great. But I think the equivalent
>> master updates for the server tests are missing. In particular, I
>> think it'd be good to run the "derbynet/dblook_test_net.java" test
>> against the Network Server and update the master files accordingly.
>> There are two masters, one for the test with JCC and one for the test
>> with the Derby Network Client.
>>
>> The reason I list this as "most importantly" is because when I myself
>> tried to run dblook_test_net against the server, I got a DRDA
>> protocol exception with the "GENERATED BY DEFAULT" column. I looked
>> into this some more and, after removing your patch, I was able to
>> figure out that the problem isn't with your DERBY-308 patch so much
>> as with GENERATED BY DEFAULT columns in general. I will file a
>> separate JIRA defect for that problem next--but in the meantime, I
>> think this is a good example of why we need to run tests against the
>> server as much as possible.
>>
>> My second (minor) comment on the patch is that it appears to contain
>> Japanese characters at the top of each file's diff. I think it's
>> Japanese for the words "revision" and "working copy". The patch
>> still applies in my codeline without problem, but I think it might be
>> safer to try to remove those characters from the patch before
>> submitting, if that's possible...?
>>
>> I will file a JIRA entry for the DRDA protocol problem I mentioned
>> above. You may want to wait until that protocol issue can be resolved
>> before proceeding with this DERBY-308 patch...
>>
>> Army
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.322 / Virus Database: 266.11.17 - Release Date: 2005/05/25
>>
>>
>
>
>
Re: about DERBY-318 (Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"))
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I could reproduce DERBY-318.
dblook.log@ClientSide :
-------
com.ibm.db2.jcc.c.DisconnectException: A communication error has been
detected.
Communication protocol being used: Reply.fill(). Communication API being
used: I
nputStream.read(). Location where the error was detected: insufficient data.
Com
munication function detecting the error: *. Protocol specific error codes(s)
TCP
/IP SOCKETS
at com.ibm.db2.jcc.a.a.a(a.java:426)
at com.ibm.db2.jcc.a.bb.b(bb.java:202)
com.ibm.db2.jcc.c.DisconnectException: A communication error has been
detected.
Communication protocol being used: Reply.fill(). Communication API being
used: I
nputStream.read(). Location where the error was detected: insufficient data.
Com
munication function detecting the error: *. Protocol specific error codes(s)
TCP
/IP SOCKETS
at com.ibm.db2.jcc.a.a.a(a.java:426)
at com.ibm.db2.jcc.a.bb.b(bb.java:202)
at com.ibm.db2.jcc.a.bb.c(bb.java:222)
at com.ibm.db2.jcc.a.bb.d(bb.java:236)
at com.ibm.db2.jcc.a.eb.a(eb.java:1911)
at com.ibm.db2.jcc.a.fb.a(fb.java:134)
at com.ibm.db2.jcc.a.fb.a(fb.java:34)
at com.ibm.db2.jcc.a.s.a(s.java:30)
at com.ibm.db2.jcc.a.h.Gb(h.java:325)
at com.ibm.db2.jcc.c.rc.R(rc.java:3028)
at com.ibm.db2.jcc.a.d.f(d.java:1070)
at com.ibm.db2.jcc.c.r.a(r.java:191)
at com.ibm.db2.jcc.c.rc.c(rc.java:302)
at com.ibm.db2.jcc.c.rc.next(rc.java:277)
at
org.apache.derby.impl.tools.dblook.DB_Table.createColumn(DB_Table.jav
a:143)
at
org.apache.derby.impl.tools.dblook.DB_Table.doTables(DB_Table.java:10
1)
at org.apache.derby.tools.dblook.go(dblook.java:529)
STDERR@ServerSide:
-----------------
null
java.lang.NullPointerException
at
org.apache.derby.impl.drda.DRDAConnThread.writeFdocaVal(DRDAConnThread.java:6550)
at
org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnThread.java:5973)
at
org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(DRDAConnThread.java:5796)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:595)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:226)
agentThread[DRDAConnThread_2,5,main]
null
java.lang.NullPointerException
at
org.apache.derby.impl.drda.DRDAConnThread.writeFdocaVal(DRDAConnThread.java:6550)
at
org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnThread.java:5973)
at
org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(DRDAConnThread.java:5796)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:595)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:226)
------------------
I will start to consider how to fix the contradiction ....
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, May 28, 2005 1:51 PM
Subject: about DERBY-318 (Re: DERBY-308 just be done and .... (Re: [jira]
Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS
IDENTITY"))
> Hello.
>
> First of all, thank you for your kindness !
>
> I understood the problem is that
> there exists contradiction between rs.getString() and rs.wasNull()
> for SYSCOLUMNS.COLUMNDEFAULT of column defined as GENERATED BY DEFAULT AS
> IDENTITY.
>
> I will start to see pheonemanas in my environment.
>
>
> I think we need to consider way to solve DERBY-318 .
>
> page 321 at next document says..
> http://publibfp.boulder.ibm.com/epubs/pdf/cs51rm.pdf
>
> for tables, describes default value of the column.
> The toString() method on the object stored in the table returns the text
> of the default value as specified in the
> CREATE TABLE or ALTER TABLE statement.
>
> for publication parameters, defines the default value of the parameter at
> the source,
> and the actual value of the parameter at the target
> for stored prepared statements, defines a sample value for the parameter
> used in a
> CREATE STATEMENTor ALTER STATEMENT RECOMPILE statement
> for optimization purposes
>
> This is issue about table , so it is the matter how to interpret "text of
> the default value as specified in the
> CREATE TABLE or ALTER TABLE statement"
>
> //BTW, what is publication parameters ...?
> // I took somethink like table ....
>
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "Army" <qo...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Saturday, May 28, 2005 10:03 AM
> Subject: Re: DERBY-308 just be done and .... (Re: [jira] Updated:
> (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
>
>
>> TomohitoNakayama wrote:
>>
>>> If possible , I want to work for DERBY-318 before DERBY-308 ....
>>
>> Tomohito,
>>
>> I hope you don't mind, but when I filed DERBY-318, I wasn't sure whether
>> the problem was with the DERBY-167 patch or with the server. So, in
>> order to keep you from spending your time trying to track down a problem
>> that wasn't your fault, I started looking at this issue from the server
>> side of things--and I think I've found the problem.
>>
>> To make a long story short, the NPE in the server happens because of the
>> "toString()" method defined in DefaultNodeImpl.
>>
>> Why? Well, I try to explain it below. Excuse the formality of it all,
>> but I had to do it this way in order to keep it clear in my own head ;)
>>
>> There are several pieces that make up the puzzle. Let me start by saying
>> what they are, and then I'll try to tie them together.
>>
>> ---------------
>> -- The pieces.
>> ---------------
>>
>> 1) For a column that is GENERATED BY DEFAULT, the 'defaultText' variable
>> in the corresponding DefaultNodeImpl is null. Since
>> DefaultNodeImpl.toString() just returns defaultText, the result of
>> toString() on a DefaultNodeImpl that is GENERATED BY DEFAULT is null.
>>
>> 2) The underlying DataTypeDescriptor for all default columns is
>> "org.apache.derby.iapi.types.UserType". In that class, the "isNull()"
>> method is simply written to return "(value == null)", while the
>> "getString()" method is as follows:
>>
>> public String getString()
>> {
>> if (! isNull())
>> {
>> return value.toString();
>> }
>> else
>> {
>> return null;
>> }
>> }
>>
>> 3) For a column that is GENERATED BY DEFAULT, the 'value' variable in
>> UserType is a non-null instance of DefaultNodeImpl.
>>
>> ---------------
>> -- The problem.
>> ---------------
>>
>> In Network Server, we take the result set from the query "SELECT
>> COLUMNDEFAULT FROM SYS.SYSCOLUMNS" and we do two things. First, we call
>> rs.getString(<columnNum>), and then we call rs.wasNull().
>>
>> [ ** rs.getString() ** ]
>>
>> * The call to rs.getString(...) on the "COLUMNDEFAULT" column ultimately
>> makes a call to UserType.getString() (Piece #2).
>>
>> * That method in turn calls UserType.isNull().
>>
>> * UserType.isNull() looks at 'value', which is a non-null instance of
>> DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns
>> "false" (Piece #2).
>>
>> * UserType.getString() looks at the result from UserType.isNull(), which
>> is "false". It then calls "value.toString()" (Piece #2).
>>
>> * Since 'value' is an instance of DefaultNodeImpl (Piece #3), this ends
>> up being a call to DefaultNodeImpl.toString().
>>
>> * DefaultNodeImpl.toString() just returns 'defaultText', which is null
>> for columns that are GENERATED BY DEFAULT (Piece #1).
>>
>> * UserType.getString() returns the null value that it got from
>> DefaultNodeImpl.toString().
>>
>> * End result: the server call to "rs.getString()" returns null.
>>
>> [ ** rs.wasNull() ** ]
>>
>> * The server call to rs.wasNull() on the "COLUMNDEFAULT" column
>> ultimately makes a call to UserType.isNull().
>>
>> * UserType.isNull() looks at 'value', which is a non-null instance of
>> DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns
>> "false" (Piece #2).
>>
>> * End result: the server call to "rs.wasNull()" returns FALSE.
>>
>> THEREFORE, the server calls rs.getString() and gets NULL back, but then
>> when it calls rs.wasNull(), it's told that the value it got back was NOT
>> null. So it tries to use the value (which IS null) and ends up with a
>> Null Pointer Exception.
>>
>> ---------------
>> Possible fix:
>> ---------------
>>
>> Just to verify that this is in the fact the problem, I changed the
>> "toString()" method in DefaultNodeImpl to the following:
>>
>> public String toString()
>> {
>> if (isDefaultValueAutoinc())
>> return "GENERATED BY DEFAULT";
>> return defaultText;
>> }
>>
>> What this means is that the server call to rs.getString() will now return
>> "GENERATED BY DEFAULT" instead of null. This in turn means that the
>> result of rs.wasNull() will be correct, and the result of the query
>> "SELECT COLUMNDEFAULT FROM SYS.SYSCOLUMNS" will be the string "GENERATED
>> BY DEFAULT".
>>
>> I then ran the repro described in DERBY-318, and it ran correctly,
>> listing "GENERATED BY DEFAULT" as the default value for the column in
>> question.
>>
>> That said, I think returning any non-null value in
>> DefaultNodeImpl.toString() will solve the problem The question then
>> becomes what value should we return? Is "GENERATED BY DEFAULT" an
>> acceptable result? To me, that seems like it should be okay--it says
>> that the default value isn't known, but that it's generated at insertion
>> time, if needed. But that's just me--it's quite possible other people
>> out there have a different opinion...
>>
>> ---------------
>> Conclusion:
>> ---------------
>>
>> 1) This is NOT a Network Server problem (which is what I wanted to find
>> out, and that's why I started looking at it).
>>
>> 2) This problem can be fixed with two lines :) But I leave it up to the
>> others on this list to decide if this is the _best_ fix, and to decide on
>> what the non-null string value should be...
>>
>> I hope that helps, and I hope you don't feel cheated because I took the
>> time to look into this. As I said, I wanted to make sure you weren't
>> chasing a problem that had its origins in Network Server...
>>
>> Army
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
>>
>>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
about DERBY-318 (Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"))
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
First of all, thank you for your kindness !
I understood the problem is that
there exists contradiction between rs.getString() and rs.wasNull()
for SYSCOLUMNS.COLUMNDEFAULT of column defined as GENERATED BY DEFAULT AS
IDENTITY.
I will start to see pheonemanas in my environment.
I think we need to consider way to solve DERBY-318 .
page 321 at next document says..
http://publibfp.boulder.ibm.com/epubs/pdf/cs51rm.pdf
for tables, describes default value of the column.
The toString() method on the object stored in the table returns the text of
the default value as specified in the
CREATE TABLE or ALTER TABLE statement.
for publication parameters, defines the default value of the parameter at
the source,
and the actual value of the parameter at the target
for stored prepared statements, defines a sample value for the parameter
used in a
CREATE STATEMENTor ALTER STATEMENT RECOMPILE statement
for optimization purposes
This is issue about table , so it is the matter how to interpret "text of
the default value as specified in the
CREATE TABLE or ALTER TABLE statement"
//BTW, what is publication parameters ...?
// I took somethink like table ....
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Army" <qo...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, May 28, 2005 10:03 AM
Subject: Re: DERBY-308 just be done and .... (Re: [jira] Updated:
(DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
> TomohitoNakayama wrote:
>
>> If possible , I want to work for DERBY-318 before DERBY-308 ....
>
> Tomohito,
>
> I hope you don't mind, but when I filed DERBY-318, I wasn't sure whether
> the problem was with the DERBY-167 patch or with the server. So, in order
> to keep you from spending your time trying to track down a problem that
> wasn't your fault, I started looking at this issue from the server side of
> things--and I think I've found the problem.
>
> To make a long story short, the NPE in the server happens because of the
> "toString()" method defined in DefaultNodeImpl.
>
> Why? Well, I try to explain it below. Excuse the formality of it all,
> but I had to do it this way in order to keep it clear in my own head ;)
>
> There are several pieces that make up the puzzle. Let me start by saying
> what they are, and then I'll try to tie them together.
>
> ---------------
> -- The pieces.
> ---------------
>
> 1) For a column that is GENERATED BY DEFAULT, the 'defaultText' variable
> in the corresponding DefaultNodeImpl is null. Since
> DefaultNodeImpl.toString() just returns defaultText, the result of
> toString() on a DefaultNodeImpl that is GENERATED BY DEFAULT is null.
>
> 2) The underlying DataTypeDescriptor for all default columns is
> "org.apache.derby.iapi.types.UserType". In that class, the "isNull()"
> method is simply written to return "(value == null)", while the
> "getString()" method is as follows:
>
> public String getString()
> {
> if (! isNull())
> {
> return value.toString();
> }
> else
> {
> return null;
> }
> }
>
> 3) For a column that is GENERATED BY DEFAULT, the 'value' variable in
> UserType is a non-null instance of DefaultNodeImpl.
>
> ---------------
> -- The problem.
> ---------------
>
> In Network Server, we take the result set from the query "SELECT
> COLUMNDEFAULT FROM SYS.SYSCOLUMNS" and we do two things. First, we call
> rs.getString(<columnNum>), and then we call rs.wasNull().
>
> [ ** rs.getString() ** ]
>
> * The call to rs.getString(...) on the "COLUMNDEFAULT" column ultimately
> makes a call to UserType.getString() (Piece #2).
>
> * That method in turn calls UserType.isNull().
>
> * UserType.isNull() looks at 'value', which is a non-null instance of
> DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns
> "false" (Piece #2).
>
> * UserType.getString() looks at the result from UserType.isNull(), which
> is "false". It then calls "value.toString()" (Piece #2).
>
> * Since 'value' is an instance of DefaultNodeImpl (Piece #3), this ends up
> being a call to DefaultNodeImpl.toString().
>
> * DefaultNodeImpl.toString() just returns 'defaultText', which is null for
> columns that are GENERATED BY DEFAULT (Piece #1).
>
> * UserType.getString() returns the null value that it got from
> DefaultNodeImpl.toString().
>
> * End result: the server call to "rs.getString()" returns null.
>
> [ ** rs.wasNull() ** ]
>
> * The server call to rs.wasNull() on the "COLUMNDEFAULT" column ultimately
> makes a call to UserType.isNull().
>
> * UserType.isNull() looks at 'value', which is a non-null instance of
> DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns
> "false" (Piece #2).
>
> * End result: the server call to "rs.wasNull()" returns FALSE.
>
> THEREFORE, the server calls rs.getString() and gets NULL back, but then
> when it calls rs.wasNull(), it's told that the value it got back was NOT
> null. So it tries to use the value (which IS null) and ends up with a
> Null Pointer Exception.
>
> ---------------
> Possible fix:
> ---------------
>
> Just to verify that this is in the fact the problem, I changed the
> "toString()" method in DefaultNodeImpl to the following:
>
> public String toString()
> {
> if (isDefaultValueAutoinc())
> return "GENERATED BY DEFAULT";
> return defaultText;
> }
>
> What this means is that the server call to rs.getString() will now return
> "GENERATED BY DEFAULT" instead of null. This in turn means that the
> result of rs.wasNull() will be correct, and the result of the query
> "SELECT COLUMNDEFAULT FROM SYS.SYSCOLUMNS" will be the string "GENERATED
> BY DEFAULT".
>
> I then ran the repro described in DERBY-318, and it ran correctly, listing
> "GENERATED BY DEFAULT" as the default value for the column in question.
>
> That said, I think returning any non-null value in
> DefaultNodeImpl.toString() will solve the problem The question then
> becomes what value should we return? Is "GENERATED BY DEFAULT" an
> acceptable result? To me, that seems like it should be okay--it says that
> the default value isn't known, but that it's generated at insertion time,
> if needed. But that's just me--it's quite possible other people out there
> have a different opinion...
>
> ---------------
> Conclusion:
> ---------------
>
> 1) This is NOT a Network Server problem (which is what I wanted to find
> out, and that's why I started looking at it).
>
> 2) This problem can be fixed with two lines :) But I leave it up to the
> others on this list to decide if this is the _best_ fix, and to decide on
> what the non-null string value should be...
>
> I hope that helps, and I hope you don't feel cheated because I took the
> time to look into this. As I said, I wanted to make sure you weren't
> chasing a problem that had its origins in Network Server...
>
> Army
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
Discussion about DERBY-318 (Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"))
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
"This issue" means DERBY-318.
Well....
New subject of mail for DERBY-318 was needed .
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Monday, May 30, 2005 8:56 PM
Subject: Re: DERBY-308 just be done and .... (Re: [jira] Updated:
(DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
> Hello.
>
> I consider this issue in last weekend and agree your opinion in general.
> "in general" means that I think "GENERATED_BY_DEFAULT" is better.
>
> To think manipulating the value in some script, no space in this value
> would be better.
> How do others think ?
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "Army" <qo...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Saturday, May 28, 2005 10:03 AM
> Subject: Re: DERBY-308 just be done and .... (Re: [jira] Updated:
> (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
>
>
>> TomohitoNakayama wrote:
>>
>>> If possible , I want to work for DERBY-318 before DERBY-308 ....
>>
>> Tomohito,
>>
>> I hope you don't mind, but when I filed DERBY-318, I wasn't sure whether
>> the problem was with the DERBY-167 patch or with the server. So, in
>> order to keep you from spending your time trying to track down a problem
>> that wasn't your fault, I started looking at this issue from the server
>> side of things--and I think I've found the problem.
>>
>> To make a long story short, the NPE in the server happens because of the
>> "toString()" method defined in DefaultNodeImpl.
>>
>> Why? Well, I try to explain it below. Excuse the formality of it all,
>> but I had to do it this way in order to keep it clear in my own head ;)
>>
>> There are several pieces that make up the puzzle. Let me start by saying
>> what they are, and then I'll try to tie them together.
>>
>> ---------------
>> -- The pieces.
>> ---------------
>>
>> 1) For a column that is GENERATED BY DEFAULT, the 'defaultText' variable
>> in the corresponding DefaultNodeImpl is null. Since
>> DefaultNodeImpl.toString() just returns defaultText, the result of
>> toString() on a DefaultNodeImpl that is GENERATED BY DEFAULT is null.
>>
>> 2) The underlying DataTypeDescriptor for all default columns is
>> "org.apache.derby.iapi.types.UserType". In that class, the "isNull()"
>> method is simply written to return "(value == null)", while the
>> "getString()" method is as follows:
>>
>> public String getString()
>> {
>> if (! isNull())
>> {
>> return value.toString();
>> }
>> else
>> {
>> return null;
>> }
>> }
>>
>> 3) For a column that is GENERATED BY DEFAULT, the 'value' variable in
>> UserType is a non-null instance of DefaultNodeImpl.
>>
>> ---------------
>> -- The problem.
>> ---------------
>>
>> In Network Server, we take the result set from the query "SELECT
>> COLUMNDEFAULT FROM SYS.SYSCOLUMNS" and we do two things. First, we call
>> rs.getString(<columnNum>), and then we call rs.wasNull().
>>
>> [ ** rs.getString() ** ]
>>
>> * The call to rs.getString(...) on the "COLUMNDEFAULT" column ultimately
>> makes a call to UserType.getString() (Piece #2).
>>
>> * That method in turn calls UserType.isNull().
>>
>> * UserType.isNull() looks at 'value', which is a non-null instance of
>> DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns
>> "false" (Piece #2).
>>
>> * UserType.getString() looks at the result from UserType.isNull(), which
>> is "false". It then calls "value.toString()" (Piece #2).
>>
>> * Since 'value' is an instance of DefaultNodeImpl (Piece #3), this ends
>> up being a call to DefaultNodeImpl.toString().
>>
>> * DefaultNodeImpl.toString() just returns 'defaultText', which is null
>> for columns that are GENERATED BY DEFAULT (Piece #1).
>>
>> * UserType.getString() returns the null value that it got from
>> DefaultNodeImpl.toString().
>>
>> * End result: the server call to "rs.getString()" returns null.
>>
>> [ ** rs.wasNull() ** ]
>>
>> * The server call to rs.wasNull() on the "COLUMNDEFAULT" column
>> ultimately makes a call to UserType.isNull().
>>
>> * UserType.isNull() looks at 'value', which is a non-null instance of
>> DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns
>> "false" (Piece #2).
>>
>> * End result: the server call to "rs.wasNull()" returns FALSE.
>>
>> THEREFORE, the server calls rs.getString() and gets NULL back, but then
>> when it calls rs.wasNull(), it's told that the value it got back was NOT
>> null. So it tries to use the value (which IS null) and ends up with a
>> Null Pointer Exception.
>>
>> ---------------
>> Possible fix:
>> ---------------
>>
>> Just to verify that this is in the fact the problem, I changed the
>> "toString()" method in DefaultNodeImpl to the following:
>>
>> public String toString()
>> {
>> if (isDefaultValueAutoinc())
>> return "GENERATED BY DEFAULT";
>> return defaultText;
>> }
>>
>> What this means is that the server call to rs.getString() will now return
>> "GENERATED BY DEFAULT" instead of null. This in turn means that the
>> result of rs.wasNull() will be correct, and the result of the query
>> "SELECT COLUMNDEFAULT FROM SYS.SYSCOLUMNS" will be the string "GENERATED
>> BY DEFAULT".
>>
>> I then ran the repro described in DERBY-318, and it ran correctly,
>> listing "GENERATED BY DEFAULT" as the default value for the column in
>> question.
>>
>> That said, I think returning any non-null value in
>> DefaultNodeImpl.toString() will solve the problem The question then
>> becomes what value should we return? Is "GENERATED BY DEFAULT" an
>> acceptable result? To me, that seems like it should be okay--it says
>> that the default value isn't known, but that it's generated at insertion
>> time, if needed. But that's just me--it's quite possible other people
>> out there have a different opinion...
>>
>> ---------------
>> Conclusion:
>> ---------------
>>
>> 1) This is NOT a Network Server problem (which is what I wanted to find
>> out, and that's why I started looking at it).
>>
>> 2) This problem can be fixed with two lines :) But I leave it up to the
>> others on this list to decide if this is the _best_ fix, and to decide on
>> what the non-null string value should be...
>>
>> I hope that helps, and I hope you don't feel cheated because I took the
>> time to look into this. As I said, I wanted to make sure you weren't
>> chasing a problem that had its origins in Network Server...
>>
>> Army
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
>>
>>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
Re: DERBY-318(Re: DERBY-308 just be done and ....
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
This patch is committed. Thanks!
Satheesh
Sending
java\testing\org\apache\derbyTesting\functionTests\master\dblook_test.out
Sending
java\testing\org\apache\derbyTesting\functionTests\tests\tools\dblook_makeDB.sql
Sending java\tools\org\apache\derby\impl\tools\dblook\DB_Table.java
Transmitting file data ...
Committed revision 179693.
TomohitoNakayama wrote:
> Hello.
>
> Thank you.
>
> I have uploaded patch.
> There found three error in result of derbyall.
>
> I don't think they are caused by my modification...
> I will execute derbyall again and confirm it.
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Army" <qo...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Thursday, June 02, 2005 1:04 AM
> Subject: Re: DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira]
> Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS
> IDENTITY"))
>
>
>> TomohitoNakayama wrote:
>>
>>> I concluded as next.
>>> Thinking "GENERATED BY DEFAULT AS IDENTITY" is a kind of default,
>>> returning not null value for that column does not cause problem.
>>> On the contrast , returning null value for column of "GENERATED BY
>>> DEFAULT AS IDENTITY"
>>> may cause some inconsistency, because the column is a column with
>>> special default value.
>>>
>>
>> Well, a GENERATED ALWAYS AS IDENTITY column is also "a column with
>> special default value", and yet Derby currently returns null for the
>> default of that kind of column. So to make GENERATED BY DEFAULT
>> columns match this behavior (by returning null) is, I think, the most
>> consistent thing.
>>
>> On the other hand, I agree that a non-null string such as
>> "GENERATED_BY_DEFAULT" has its benefits, as well. Since no one else
>> has commented one way or the other, and since I think we should get
>> this issue resolved sooner rather than later, I think you can go
>> ahead and do things the way you think is best.
>>
>> So please feel free to make the change as you prefer, and to post the
>> patch to the list so we can proceed.
>>
>> Thanks!
>> Army
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.322 / Virus Database: 267.4.0 - Release Date: 2005/06/01
>>
>>
>
>
>
Re: DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira] Updated:
(DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"))
Posted by Kathey Marsden <km...@sbcglobal.net>.
TomohitoNakayama wrote:
>
> I had continued testing DERBY-318.
>
> Before, I found errors in next three test with modification of DERBY-318.
> derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/dataSourcePermissions_net
[snip other test info]
This may be DERBY-273
http://issues.apache.org/jira/browse/DERBY-273
If my initial analysis of this failure is correct it should be fairly
easy to fix. Of course nothing seems easy these days. I hope someone
has the time to pick it up.
Kathey
Re: DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"))
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Thank you for finishing DERBY-318 and 308 !
I had continued testing DERBY-318.
Before, I found errors in next three test with modification of DERBY-318.
derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/dataSourcePermissions_net derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/updatableResultSet derbyall/storeall/storemore/OnlineCompressTestI ran derbyall without modification of DERBY-318 and error was found only in"updatableResultSet.diff".Hence ,errors in dataSourcePermissions_net and OnlineCompressTest.java ,might be caused by modification of DERBY-318.To know much about errors,I ran tests with modification of DERBY-318 individually.However, none of these test failed in individual testing.I conclude errors found in derbyall after modification of DERBY-318 happenindeterminately and,they does not imply regression by DERBY-318.Best regards./* Tomohito Nakayama tomonaka@basil.ocn.ne.jp tomohito@rose.zero.ad.jp Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html*/ ----- Original Message ----- From: Satheesh Bandaram To: Derby Development Sent: Friday, June 03, 2005 12:05 PM Suject: Re: DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira]Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT ASIDENTITY")) Hi Tomohito, Once I applied both your patches, I found some problems. The problemswere: 1.. We needed to update dblook_test_net.out in both DerbyNet andDerbyNetClient directories. 2.. Found a small problem in dblook itself. It was generating defaultinfo for identity columns also, since toString() now returnsGENERATED_BY_DEFAULT string. dblook needed to be modified. I applied the changes already. I think everything should be fine now.Please look at my changes below. If they are incorrect, feel free to sendanother patch. You can see the actual changes by: svn diff -r179707:179708 Satheesh Sendingjava\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\dblook_test_net.out Sendingjava\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\dblook_test_net.out Sendingjava\testing\org\apache\derbyTesting\functionTests\master\dblook_est.out Sending java\tools\org\apache\derby\impl\tools\dblook\DB_Table.java Transmitting file data .... Committed revision 179708. TomohitoNakayama wrote: Hello. Thank you. I have uploaded patch. There found three error in result of derbyall. I don't think they are caused by my modification... I will execute derbyall again and confirm it. Best regards. /* Tomohito Nakayama tomonaka@basil.ocn.ne.jp tomohito@rose.zero.ad.jp Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */ ----- Original Message ----- From: "Army" <qo...@sbcglobal.net> To: "Derby Development" <de...@db.apache.org> Sent: Thursday, June 02, 2005 1:04 AM Subject: Re: DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira]Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT ASIDENTITY")) TomohitoNakayama wrote: I concluded as next. Thinking "GENERATED BY DEFAULT AS IDENTITY" is a kind of default, returning not null value for that column does not cause problem. On the contrast , returning null value for column of "GENERATED BYDEFAULT AS IDENTITY" may cause some inconsistency, because the column is a column withspecial default value. Well, a GENERATED ALWAYS AS IDENTITY column is also "a column withspecial default value", and yet Derby currently returns null for the defaultof that kind of column. So to make GENERATED BY DEFAULT columns match thisbehavior (by returning null) is, I think, the most consistent thing. On the other hand, I agree that a non-null string such as"GENERATED_BY_DEFAULT" has its benefits, as well. Since no one else hascommented one way or the other, and since I think we should get this issueresolved sooner rather than later, I think you can go ahead and do thingsthe way you think is best. So please feel free to make the change as you prefer, and to post thepatch to the list so we can proceed. Thanks! Army -- No virus found in tis incoming message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.4.0 - Release Date: 2005/06/01------------------------------------------------------------------------------ No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.1 - Release Date: 2005/06/03
Re: DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"))
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Thank you.
I have uploaded patch.
There found three error in result of derbyall.
I don't think they are caused by my modification...
I will execute derbyall again and confirm it.
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Army" <qo...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Thursday, June 02, 2005 1:04 AM
Subject: Re: DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira]
Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS
IDENTITY"))
> TomohitoNakayama wrote:
>
>> I concluded as next.
>> Thinking "GENERATED BY DEFAULT AS IDENTITY" is a kind of default,
>> returning not null value for that column does not cause problem.
>> On the contrast , returning null value for column of "GENERATED BY
>> DEFAULT AS IDENTITY"
>> may cause some inconsistency, because the column is a column with special
>> default value.
>>
>
> Well, a GENERATED ALWAYS AS IDENTITY column is also "a column with special
> default value", and yet Derby currently returns null for the default of
> that kind of column. So to make GENERATED BY DEFAULT columns match this
> behavior (by returning null) is, I think, the most consistent thing.
>
> On the other hand, I agree that a non-null string such as
> "GENERATED_BY_DEFAULT" has its benefits, as well. Since no one else has
> commented one way or the other, and since I think we should get this issue
> resolved sooner rather than later, I think you can go ahead and do things
> the way you think is best.
>
> So please feel free to make the change as you prefer, and to post the
> patch to the list so we can proceed.
>
> Thanks!
> Army
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.4.0 - Release Date: 2005/06/01
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.4.1 - Release Date: 2005/06/02
Re: DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira] Updated:
(DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"))
Posted by Army <qo...@sbcglobal.net>.
TomohitoNakayama wrote:
> I concluded as next.
> Thinking "GENERATED BY DEFAULT AS IDENTITY" is a kind of default,
> returning not null value for that column does not cause problem.
> On the contrast , returning null value for column of "GENERATED BY
> DEFAULT AS IDENTITY"
> may cause some inconsistency, because the column is a column with
> special default value.
>
Well, a GENERATED ALWAYS AS IDENTITY column is also "a column with special
default value", and yet Derby currently returns null for the default of that
kind of column. So to make GENERATED BY DEFAULT columns match this behavior (by
returning null) is, I think, the most consistent thing.
On the other hand, I agree that a non-null string such as "GENERATED_BY_DEFAULT"
has its benefits, as well. Since no one else has commented one way or the
other, and since I think we should get this issue resolved sooner rather than
later, I think you can go ahead and do things the way you think is best.
So please feel free to make the change as you prefer, and to post the patch to
the list so we can proceed.
Thanks!
Army
DERBY-318(Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"))
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Army wrote :
> The safest (consistent) thing to do is to return NULL for columns that are
> GENERATED BY DEFAULT, so I think that's what I would vote for (despite my
> initial email saying otherwise). But that's just me--I hope anyone who
> feels otherwise will post saying so...
My thought ...
I concluded as next.
Thinking "GENERATED BY DEFAULT AS IDENTITY" is a kind of default,
returning not null value for that column does not cause problem.
On the contrast , returning null value for column of "GENERATED BY DEFAULT
AS IDENTITY"
may cause some inconsistency, because the column is a column with special
default value.
Of cource, regression test is neccesary,
because there remains anxiety.
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Army" <qo...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Tuesday, May 31, 2005 1:39 AM
Subject: Re: DERBY-308 just be done and .... (Re: [jira] Updated:
(DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
> TomohitoNakayama wrote:
>> Hello.
>>
>> I consider this issue in last weekend and agree your opinion in general.
>> "in general" means that I think "GENERATED_BY_DEFAULT" is better.
>>
>> To think manipulating the value in some script, no space in this value
>> would be better.
>> How do others think ?
>
> The only issue with this is consistency. For a column that's "GENERATED
> ALWAYS", Derby currently returns NULL for the default text. In order to
> be consistent, I think we should have the same behavior for the two types
> of columns: either return NULL for the default text in both cases, or else
> return some constant string.
>
> But that said, if we change GENERATED ALWAYS columns to return a non-null
> value (such as "GENERATED_ALWAYS"), then there's the chance that we
> introduce a regression: any users of the 10.0 release who expect a NULL
> will now get different behavior. I don't know if that's acceptable...?
>
> The safest (consistent) thing to do is to return NULL for columns that are
> GENERATED BY DEFAULT, so I think that's what I would vote for (despite my
> initial email saying otherwise). But that's just me--I hope anyone who
> feels otherwise will post saying so...
>
> Army
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 5/27/2005
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 5/27/2005
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308)
Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by Army <qo...@sbcglobal.net>.
TomohitoNakayama wrote:
> Hello.
>
> I consider this issue in last weekend and agree your opinion in general.
> "in general" means that I think "GENERATED_BY_DEFAULT" is better.
>
> To think manipulating the value in some script, no space in this value
> would be better.
> How do others think ?
The only issue with this is consistency. For a column that's "GENERATED
ALWAYS", Derby currently returns NULL for the default text. In order to be
consistent, I think we should have the same behavior for the two types of
columns: either return NULL for the default text in both cases, or else return
some constant string.
But that said, if we change GENERATED ALWAYS columns to return a non-null value
(such as "GENERATED_ALWAYS"), then there's the chance that we introduce a
regression: any users of the 10.0 release who expect a NULL will now get
different behavior. I don't know if that's acceptable...?
The safest (consistent) thing to do is to return NULL for columns that are
GENERATED BY DEFAULT, so I think that's what I would vote for (despite my
initial email saying otherwise). But that's just me--I hope anyone who feels
otherwise will post saying so...
Army
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I consider this issue in last weekend and agree your opinion in general.
"in general" means that I think "GENERATED_BY_DEFAULT" is better.
To think manipulating the value in some script, no space in this value would
be better.
How do others think ?
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Army" <qo...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, May 28, 2005 10:03 AM
Subject: Re: DERBY-308 just be done and .... (Re: [jira] Updated:
(DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
> TomohitoNakayama wrote:
>
>> If possible , I want to work for DERBY-318 before DERBY-308 ....
>
> Tomohito,
>
> I hope you don't mind, but when I filed DERBY-318, I wasn't sure whether
> the problem was with the DERBY-167 patch or with the server. So, in order
> to keep you from spending your time trying to track down a problem that
> wasn't your fault, I started looking at this issue from the server side of
> things--and I think I've found the problem.
>
> To make a long story short, the NPE in the server happens because of the
> "toString()" method defined in DefaultNodeImpl.
>
> Why? Well, I try to explain it below. Excuse the formality of it all,
> but I had to do it this way in order to keep it clear in my own head ;)
>
> There are several pieces that make up the puzzle. Let me start by saying
> what they are, and then I'll try to tie them together.
>
> ---------------
> -- The pieces.
> ---------------
>
> 1) For a column that is GENERATED BY DEFAULT, the 'defaultText' variable
> in the corresponding DefaultNodeImpl is null. Since
> DefaultNodeImpl.toString() just returns defaultText, the result of
> toString() on a DefaultNodeImpl that is GENERATED BY DEFAULT is null.
>
> 2) The underlying DataTypeDescriptor for all default columns is
> "org.apache.derby.iapi.types.UserType". In that class, the "isNull()"
> method is simply written to return "(value == null)", while the
> "getString()" method is as follows:
>
> public String getString()
> {
> if (! isNull())
> {
> return value.toString();
> }
> else
> {
> return null;
> }
> }
>
> 3) For a column that is GENERATED BY DEFAULT, the 'value' variable in
> UserType is a non-null instance of DefaultNodeImpl.
>
> ---------------
> -- The problem.
> ---------------
>
> In Network Server, we take the result set from the query "SELECT
> COLUMNDEFAULT FROM SYS.SYSCOLUMNS" and we do two things. First, we call
> rs.getString(<columnNum>), and then we call rs.wasNull().
>
> [ ** rs.getString() ** ]
>
> * The call to rs.getString(...) on the "COLUMNDEFAULT" column ultimately
> makes a call to UserType.getString() (Piece #2).
>
> * That method in turn calls UserType.isNull().
>
> * UserType.isNull() looks at 'value', which is a non-null instance of
> DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns
> "false" (Piece #2).
>
> * UserType.getString() looks at the result from UserType.isNull(), which
> is "false". It then calls "value.toString()" (Piece #2).
>
> * Since 'value' is an instance of DefaultNodeImpl (Piece #3), this ends up
> being a call to DefaultNodeImpl.toString().
>
> * DefaultNodeImpl.toString() just returns 'defaultText', which is null for
> columns that are GENERATED BY DEFAULT (Piece #1).
>
> * UserType.getString() returns the null value that it got from
> DefaultNodeImpl.toString().
>
> * End result: the server call to "rs.getString()" returns null.
>
> [ ** rs.wasNull() ** ]
>
> * The server call to rs.wasNull() on the "COLUMNDEFAULT" column ultimately
> makes a call to UserType.isNull().
>
> * UserType.isNull() looks at 'value', which is a non-null instance of
> DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns
> "false" (Piece #2).
>
> * End result: the server call to "rs.wasNull()" returns FALSE.
>
> THEREFORE, the server calls rs.getString() and gets NULL back, but then
> when it calls rs.wasNull(), it's told that the value it got back was NOT
> null. So it tries to use the value (which IS null) and ends up with a
> Null Pointer Exception.
>
> ---------------
> Possible fix:
> ---------------
>
> Just to verify that this is in the fact the problem, I changed the
> "toString()" method in DefaultNodeImpl to the following:
>
> public String toString()
> {
> if (isDefaultValueAutoinc())
> return "GENERATED BY DEFAULT";
> return defaultText;
> }
>
> What this means is that the server call to rs.getString() will now return
> "GENERATED BY DEFAULT" instead of null. This in turn means that the
> result of rs.wasNull() will be correct, and the result of the query
> "SELECT COLUMNDEFAULT FROM SYS.SYSCOLUMNS" will be the string "GENERATED
> BY DEFAULT".
>
> I then ran the repro described in DERBY-318, and it ran correctly, listing
> "GENERATED BY DEFAULT" as the default value for the column in question.
>
> That said, I think returning any non-null value in
> DefaultNodeImpl.toString() will solve the problem The question then
> becomes what value should we return? Is "GENERATED BY DEFAULT" an
> acceptable result? To me, that seems like it should be okay--it says that
> the default value isn't known, but that it's generated at insertion time,
> if needed. But that's just me--it's quite possible other people out there
> have a different opinion...
>
> ---------------
> Conclusion:
> ---------------
>
> 1) This is NOT a Network Server problem (which is what I wanted to find
> out, and that's why I started looking at it).
>
> 2) This problem can be fixed with two lines :) But I leave it up to the
> others on this list to decide if this is the _best_ fix, and to decide on
> what the non-null string value should be...
>
> I hope that helps, and I hope you don't feel cheated because I took the
> time to look into this. As I said, I wanted to make sure you weren't
> chasing a problem that had its origins in Network Server...
>
> Army
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 2005/05/27
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308)
Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by Army <qo...@sbcglobal.net>.
Oops. In that last email, replace all occurrences of "DefaultNodeImpl" with
"DefaultInfoImpl". For some reason the wrong file name was in my head.
Army wrote:
> That said, I think returning any non-null value in
> DefaultNodeImpl.toString() will solve the problem The question then
> becomes what value should we return?
[snip]
> 2) This problem can be fixed with two lines :) But I leave it up to the
> others on this list to decide if this is the _best_ fix, and to decide
> on what the non-null string value should be...
Actually, as I thought about this on my ride home, I realized that changing
DefaultInfoImpl.toString() is probably not the best fix. To be consistent with
GENERATED ALWAYS columns, which return null as the default, GENERATED BY DEFAULT
should probably return null, as well. This means that the method that should
change is UserType.isNull().
Something like:
public final boolean isNull()
{
if (value == null)
return true;
if (value instanceof DefaultInfoImpl)
return (((DefaultInfoImpl)value).getDefaultText() == null);
return false;
}
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308)
Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by Army <qo...@sbcglobal.net>.
TomohitoNakayama wrote:
> If possible , I want to work for DERBY-318 before DERBY-308 ....
Tomohito,
I hope you don't mind, but when I filed DERBY-318, I wasn't sure whether the
problem was with the DERBY-167 patch or with the server. So, in order to keep
you from spending your time trying to track down a problem that wasn't your
fault, I started looking at this issue from the server side of things--and I
think I've found the problem.
To make a long story short, the NPE in the server happens because of the
"toString()" method defined in DefaultNodeImpl.
Why? Well, I try to explain it below. Excuse the formality of it all, but I
had to do it this way in order to keep it clear in my own head ;)
There are several pieces that make up the puzzle. Let me start by saying what
they are, and then I'll try to tie them together.
---------------
-- The pieces.
---------------
1) For a column that is GENERATED BY DEFAULT, the 'defaultText' variable in the
corresponding DefaultNodeImpl is null. Since DefaultNodeImpl.toString() just
returns defaultText, the result of toString() on a DefaultNodeImpl that is
GENERATED BY DEFAULT is null.
2) The underlying DataTypeDescriptor for all default columns is
"org.apache.derby.iapi.types.UserType". In that class, the "isNull()" method is
simply written to return "(value == null)", while the "getString()" method is as
follows:
public String getString()
{
if (! isNull())
{
return value.toString();
}
else
{
return null;
}
}
3) For a column that is GENERATED BY DEFAULT, the 'value' variable in UserType
is a non-null instance of DefaultNodeImpl.
---------------
-- The problem.
---------------
In Network Server, we take the result set from the query "SELECT COLUMNDEFAULT
FROM SYS.SYSCOLUMNS" and we do two things. First, we call
rs.getString(<columnNum>), and then we call rs.wasNull().
[ ** rs.getString() ** ]
* The call to rs.getString(...) on the "COLUMNDEFAULT" column ultimately makes a
call to UserType.getString() (Piece #2).
* That method in turn calls UserType.isNull().
* UserType.isNull() looks at 'value', which is a non-null instance of
DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns "false"
(Piece #2).
* UserType.getString() looks at the result from UserType.isNull(), which is
"false". It then calls "value.toString()" (Piece #2).
* Since 'value' is an instance of DefaultNodeImpl (Piece #3), this ends up being
a call to DefaultNodeImpl.toString().
* DefaultNodeImpl.toString() just returns 'defaultText', which is null for
columns that are GENERATED BY DEFAULT (Piece #1).
* UserType.getString() returns the null value that it got from
DefaultNodeImpl.toString().
* End result: the server call to "rs.getString()" returns null.
[ ** rs.wasNull() ** ]
* The server call to rs.wasNull() on the "COLUMNDEFAULT" column ultimately makes
a call to UserType.isNull().
* UserType.isNull() looks at 'value', which is a non-null instance of
DefaultNodeImpl(Piece #3 above), and since it's NOT null, it returns "false"
(Piece #2).
* End result: the server call to "rs.wasNull()" returns FALSE.
THEREFORE, the server calls rs.getString() and gets NULL back, but then when it
calls rs.wasNull(), it's told that the value it got back was NOT null. So it
tries to use the value (which IS null) and ends up with a Null Pointer Exception.
---------------
Possible fix:
---------------
Just to verify that this is in the fact the problem, I changed the "toString()"
method in DefaultNodeImpl to the following:
public String toString()
{
if (isDefaultValueAutoinc())
return "GENERATED BY DEFAULT";
return defaultText;
}
What this means is that the server call to rs.getString() will now return
"GENERATED BY DEFAULT" instead of null. This in turn means that the result of
rs.wasNull() will be correct, and the result of the query "SELECT COLUMNDEFAULT
FROM SYS.SYSCOLUMNS" will be the string "GENERATED BY DEFAULT".
I then ran the repro described in DERBY-318, and it ran correctly, listing
"GENERATED BY DEFAULT" as the default value for the column in question.
That said, I think returning any non-null value in DefaultNodeImpl.toString()
will solve the problem The question then becomes what value should we return?
Is "GENERATED BY DEFAULT" an acceptable result? To me, that seems like it
should be okay--it says that the default value isn't known, but that it's
generated at insertion time, if needed. But that's just me--it's quite possible
other people out there have a different opinion...
---------------
Conclusion:
---------------
1) This is NOT a Network Server problem (which is what I wanted to find out, and
that's why I started looking at it).
2) This problem can be fixed with two lines :) But I leave it up to the others
on this list to decide if this is the _best_ fix, and to decide on what the
non-null string value should be...
I hope that helps, and I hope you don't feel cheated because I took the time to
look into this. As I said, I wanted to make sure you weren't chasing a problem
that had its origins in Network Server...
Army
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Reading series of other mail "Running derbyall before submitting patches",
I'm very sorry for DERBY-318....
If possible , I want to work for DERBY-318 before DERBY-308 ....
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Army" <qo...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Friday, May 27, 2005 1:56 AM
Subject: Re: DERBY-308 just be done and .... (Re: [jira] Updated:
(DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
> TomohitoNakayama wrote:
>> Hello.
>>
>> I have just done DERBY-308.
>> I uploaded patch just for reviewing.
>
> Hi Tomohito,
>
> Thanks for looking at this so quickly. A couple of comments on the patch:
>
> First and most importanly:
>
> It looks like you have run the dblook_test for embedded mode and have
> updated the master, which is great. But I think the equivalent master
> updates for the server tests are missing. In particular, I think it'd be
> good to run the "derbynet/dblook_test_net.java" test against the Network
> Server and update the master files accordingly. There are two masters,
> one for the test with JCC and one for the test with the Derby Network
> Client.
>
> The reason I list this as "most importantly" is because when I myself
> tried to run dblook_test_net against the server, I got a DRDA protocol
> exception with the "GENERATED BY DEFAULT" column. I looked into this some
> more and, after removing your patch, I was able to figure out that the
> problem isn't with your DERBY-308 patch so much as with GENERATED BY
> DEFAULT columns in general. I will file a separate JIRA defect for that
> problem next--but in the meantime, I think this is a good example of why
> we need to run tests against the server as much as possible.
>
> My second (minor) comment on the patch is that it appears to contain
> Japanese characters at the top of each file's diff. I think it's Japanese
> for the words "revision" and "working copy". The patch still applies in
> my codeline without problem, but I think it might be safer to try to
> remove those characters from the patch before submitting, if that's
> possible...?
>
> I will file a JIRA entry for the DRDA protocol problem I mentioned above.
> You may want to wait until that protocol issue can be resolved before
> proceeding with this DERBY-308 patch...
>
> Army
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.17 - Release Date: 2005/05/25
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.0.0 - Release Date: 2005/05/27
Re: DERBY-308 just be done and .... (Re: [jira] Updated: (DERBY-308)
Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY")
Posted by Army <qo...@sbcglobal.net>.
TomohitoNakayama wrote:
> Hello.
>
> I have just done DERBY-308.
> I uploaded patch just for reviewing.
Hi Tomohito,
Thanks for looking at this so quickly. A couple of comments on the patch:
First and most importanly:
It looks like you have run the dblook_test for embedded mode and have updated
the master, which is great. But I think the equivalent master updates for the
server tests are missing. In particular, I think it'd be good to run the
"derbynet/dblook_test_net.java" test against the Network Server and update the
master files accordingly. There are two masters, one for the test with JCC and
one for the test with the Derby Network Client.
The reason I list this as "most importantly" is because when I myself tried to
run dblook_test_net against the server, I got a DRDA protocol exception with the
"GENERATED BY DEFAULT" column. I looked into this some more and, after removing
your patch, I was able to figure out that the problem isn't with your DERBY-308
patch so much as with GENERATED BY DEFAULT columns in general. I will file a
separate JIRA defect for that problem next--but in the meantime, I think this is
a good example of why we need to run tests against the server as much as possible.
My second (minor) comment on the patch is that it appears to contain Japanese
characters at the top of each file's diff. I think it's Japanese for the words
"revision" and "working copy". The patch still applies in my codeline without
problem, but I think it might be safer to try to remove those characters from
the patch before submitting, if that's possible...?
I will file a JIRA entry for the DRDA protocol problem I mentioned above. You
may want to wait until that protocol issue can be resolved before proceeding
with this DERBY-308 patch...
Army