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 Mamta Satoor <ms...@gmail.com> on 2005/05/02 19:56:15 UTC
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Hi,
I am sorry if I sound like a broken record, but please, will someone
review this? And if no concerns from anyone, will a commiter commit
it?
thanks,
Mamta
On 4/27/05, Mamta Satoor <ms...@gmail.com> wrote:
> Hi,
>
> I wondered if anyone got a chance to review this patch?
>
> thanks,
> Mamta
>
> On 4/24/05, Mamta Satoor <ms...@gmail.com> wrote:
> > Hi Dan,
> >
> > I have a new patch for this bug which also fixes the problem you
> > brought up with sql select * from a.t as X. The fix for this required
> > change in impl.sql.compile.FromBaseTable's method genResultColList().
> > I changed the code such that we set the TableDescriptor on the
> > ColumnDescriptor instance. This TableDescriptor is later used by
> > ResultColumn.getTableName to get the base table name of the column. In
> > addition to that, I changed ColumnReference.getSourceTableName and
> > ColumnReference.getSourceSchemaName so that they don't look at the
> > user supplied correlation name (if any) to fetch the base table/schema
> > name.
> >
> > I have also added some test cases for the code changes above in
> > jdbcapi/resultset.java
> >
> > Other than this, the rest of the patch stays the same as what you
> > tried applying last week.
> >
> > I have run the tests and there is no new failure because of my changes.
> >
> > svn stat output
> > M java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java
> > M java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java
> > M java\engine\org\apache\derby\impl\sql\compile\CursorNode.java
> > M java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
> > M java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java
> > M java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
> > M java\engine\org\apache\derby\impl\sql\compile\ValueNode.java
> > M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
> > M java\engine\org\apache\derby\impl\sql\GenericColumnDescriptor.java
> > M java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
> > M java\engine\org\apache\derby\impl\jdbc\EmbedResultSetMetaData.java
> > M java\engine\org\apache\derby\iapi\sql\dictionary\ColumnDescriptor.java
> > M java\engine\org\apache\derby\iapi\sql\ResultColumnDescriptor.java
> > M java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
> > M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultset.java
> > M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out
> > M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\resultset.out
> > M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\updatableResultSet.out
> > M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\resultset.out
> > M java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
> > M java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
> > M java\testing\org\apache\derbyTesting\functionTests\master\resultset.out
> >
> > Please commit the patch if there are no further issues,
> > Mamta
> >
> > On 4/22/05, Mamta Satoor <ms...@gmail.com> wrote:
> > > Hi Dan,
> > >
> > > I did some research into this. You are right that for the sql
> > > select * from a.t as X
> > > the existing code will return ABC using both getTableName and
> > > getSourceTableName. Looking at the history of ColumnReference before
> > > the code was
> > > contributed, the getSourceTableName was added to Cloudscape so that
> > > ResultSetMetaData.getTableName will return the correct value which is
> > > base table
> > > name. Seems like over the time, this functionality got broken again.
> > >
> > > In my code line, I tried changing ColumnReference.getSourceTableName
> > > to following
> > > public String getSourceTableName()
> > > {
> > > return ((source != null) ? source.getTableName() : null);
> > > }
> > >
> > > But, that did not solve the problem. The source.getTableName() invokes
> > > ResultColumn.getTableName which is currently coded as follows
> > > public String getTableName()
> > > {
> > > if (tableName != null)
> > > {
> > > return tableName;
> > > }
> > > if ((columnDescriptor!=null) &&
> > > (columnDescriptor.getTableDescriptor() != null))
> > > {
> > > return columnDescriptor.getTableDescriptor().getName();
> > > }
> > > else
> > > {
> > > return expression.getTableName();
> > > }
> > > }
> > >
> > > In the code above, the first 2 if conditions return false and hence
> > > expression.getTableName() get called which returns ABC for the sql
> > > above. And this
> > > is the problem in my opinion. The 2nd if condition needs to succeed in
> > > order to get the correct value for table name(currently, the 2nd if
> > > condition
> > > returns false because columnDescriptor.getTableDescriptor() returns
> > > null). columnDescriptor has its table descriptor set to null since it
> > > got
> > > instantiated via SYSCOLUMNSRowFactory which passes the uuid for the
> > > table but not the table descriptor. I tried changing
> > > ColumnDescriptor's
> > > 2nd constructor(the one which doesn't get table descriptor passed to
> > > it) to try to get the table descriptor from the uuid by calling
> > > getDataDictionary.getTableDescriptor(uuid), but it gives me Raw Store
> > > internal error. I will continue to research but does someone looking
> > > at this
> > > explanation have any thoughts on the program flow or issue in general?
> > >
> > > thanks,
> > > Mamta
> > >
> > >
> > > On 4/20/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> > > > The patch applies fine and passes the tests but I need some
> > > > clarification on some methods in ColumnReference.
> > > >
> > > > ColumnReference has these class specific methods
> > > >
> > > > getSourceTableName()
> > > > getSourceSchemaName() [added by this contribution]
> > > >
> > > > and because it is a ValueNode it also has
> > > >
> > > > getTableName
> > > > getSchemaName
> > > >
> > > > Mamta, can you clarify the difference between the getSource*Name methods
> > > > and get*Name methods? Eventually as comments in the javadoc for these
> > > > methods, but some discussion on the list may be useful.
> > > >
> > > > I'm worried because most of the bugs around correlation names I think
> > > > were due to having multiple methods with similar and maybe misleading
> > > > names but no clear definition of what they returned.
> > > >
> > > > In this specific case, my gut reaction from the names of the
> > > > getSource*Name methods is that they return the actual name of the
> > > > underlying table the column comes from. But looking the implementation &
> > > > comments of getTableName and getSourceTableName in ColumnReference.java
> > > > it seems in this case
> > > >
> > > > select * from a.t as X
> > > >
> > > > that both methods will return X.
> > > >
> > > > Dan.
> > > >
> > > >
> > >
> >
> >
> >
>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Posted by Mamta Satoor <ms...@gmail.com>.
Thanks for looking into it, David. I just wanted to be sure that patch
has not been forgotten.
Mamta
On 5/2/05, David Van Couvering <Da...@sun.com> wrote:
> Hi, Mamta, I have actually been trying to review this patch, but this is
> my first patch review, and I am learning *a lot* about how to set up a
> clean "drop" of Derby at the revision level you are at, applying and
> reviewing a patch. I do hope in the future my response time will be better.
>
> Thanks,
>
> David
>
> Mamta Satoor wrote:
>
> > Hi,
> >
> > I am sorry if I sound like a broken record, but please, will someone
> > review this? And if no concerns from anyone, will a commiter commit
> > it?
> >
> > thanks,
> > Mamta
> >
> > On 4/27/05, Mamta Satoor <ms...@gmail.com> wrote:
> >
> >>Hi,
> >>
> >>I wondered if anyone got a chance to review this patch?
> >>
> >>thanks,
> >>Mamta
> >>
> >>On 4/24/05, Mamta Satoor <ms...@gmail.com> wrote:
> >>
> >>>Hi Dan,
> >>>
> >>>I have a new patch for this bug which also fixes the problem you
> >>>brought up with sql select * from a.t as X. The fix for this required
> >>>change in impl.sql.compile.FromBaseTable's method genResultColList().
> >>>I changed the code such that we set the TableDescriptor on the
> >>>ColumnDescriptor instance. This TableDescriptor is later used by
> >>>ResultColumn.getTableName to get the base table name of the column. In
> >>>addition to that, I changed ColumnReference.getSourceTableName and
> >>>ColumnReference.getSourceSchemaName so that they don't look at the
> >>>user supplied correlation name (if any) to fetch the base table/schema
> >>>name.
> >>>
> >>>I have also added some test cases for the code changes above in
> >>>jdbcapi/resultset.java
> >>>
> >>>Other than this, the rest of the patch stays the same as what you
> >>>tried applying last week.
> >>>
> >>>I have run the tests and there is no new failure because of my changes.
> >>>
> >>>svn stat output
> >>>M java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\CursorNode.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\ValueNode.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
> >>>M java\engine\org\apache\derby\impl\sql\GenericColumnDescriptor.java
> >>>M java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
> >>>M java\engine\org\apache\derby\impl\jdbc\EmbedResultSetMetaData.java
> >>>M java\engine\org\apache\derby\iapi\sql\dictionary\ColumnDescriptor.java
> >>>M java\engine\org\apache\derby\iapi\sql\ResultColumnDescriptor.java
> >>>M java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
> >>>M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultset.java
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\resultset.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\updatableResultSet.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\resultset.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\resultset.out
> >>>
> >>>Please commit the patch if there are no further issues,
> >>>Mamta
> >>>
> >>>On 4/22/05, Mamta Satoor <ms...@gmail.com> wrote:
> >>>
> >>>>Hi Dan,
> >>>>
> >>>>I did some research into this. You are right that for the sql
> >>>>select * from a.t as X
> >>>>the existing code will return ABC using both getTableName and
> >>>>getSourceTableName. Looking at the history of ColumnReference before
> >>>>the code was
> >>>>contributed, the getSourceTableName was added to Cloudscape so that
> >>>>ResultSetMetaData.getTableName will return the correct value which is
> >>>>base table
> >>>>name. Seems like over the time, this functionality got broken again.
> >>>>
> >>>>In my code line, I tried changing ColumnReference.getSourceTableName
> >>>>to following
> >>>>public String getSourceTableName()
> >>>>{
> >>>>return ((source != null) ? source.getTableName() : null);
> >>>>}
> >>>>
> >>>>But, that did not solve the problem. The source.getTableName() invokes
> >>>>ResultColumn.getTableName which is currently coded as follows
> >>>>public String getTableName()
> >>>>{
> >>>> if (tableName != null)
> >>>> {
> >>>> return tableName;
> >>>> }
> >>>> if ((columnDescriptor!=null) &&
> >>>> (columnDescriptor.getTableDescriptor() != null))
> >>>> {
> >>>> return columnDescriptor.getTableDescriptor().getName();
> >>>> }
> >>>> else
> >>>> {
> >>>> return expression.getTableName();
> >>>> }
> >>>>}
> >>>>
> >>>>In the code above, the first 2 if conditions return false and hence
> >>>>expression.getTableName() get called which returns ABC for the sql
> >>>>above. And this
> >>>>is the problem in my opinion. The 2nd if condition needs to succeed in
> >>>>order to get the correct value for table name(currently, the 2nd if
> >>>>condition
> >>>>returns false because columnDescriptor.getTableDescriptor() returns
> >>>>null). columnDescriptor has its table descriptor set to null since it
> >>>>got
> >>>>instantiated via SYSCOLUMNSRowFactory which passes the uuid for the
> >>>>table but not the table descriptor. I tried changing
> >>>>ColumnDescriptor's
> >>>>2nd constructor(the one which doesn't get table descriptor passed to
> >>>>it) to try to get the table descriptor from the uuid by calling
> >>>>getDataDictionary.getTableDescriptor(uuid), but it gives me Raw Store
> >>>>internal error. I will continue to research but does someone looking
> >>>>at this
> >>>>explanation have any thoughts on the program flow or issue in general?
> >>>>
> >>>>thanks,
> >>>>Mamta
> >>>>
> >>>>
> >>>>On 4/20/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> >>>>
> >>>>>The patch applies fine and passes the tests but I need some
> >>>>>clarification on some methods in ColumnReference.
> >>>>>
> >>>>>ColumnReference has these class specific methods
> >>>>>
> >>>>>getSourceTableName()
> >>>>>getSourceSchemaName() [added by this contribution]
> >>>>>
> >>>>>and because it is a ValueNode it also has
> >>>>>
> >>>>>getTableName
> >>>>>getSchemaName
> >>>>>
> >>>>>Mamta, can you clarify the difference between the getSource*Name methods
> >>>>>and get*Name methods? Eventually as comments in the javadoc for these
> >>>>>methods, but some discussion on the list may be useful.
> >>>>>
> >>>>>I'm worried because most of the bugs around correlation names I think
> >>>>>were due to having multiple methods with similar and maybe misleading
> >>>>>names but no clear definition of what they returned.
> >>>>>
> >>>>>In this specific case, my gut reaction from the names of the
> >>>>>getSource*Name methods is that they return the actual name of the
> >>>>>underlying table the column comes from. But looking the implementation &
> >>>>>comments of getTableName and getSourceTableName in ColumnReference.java
> >>>>>it seems in this case
> >>>>>
> >>>>>select * from a.t as X
> >>>>>
> >>>>>that both methods will return X.
> >>>>>
> >>>>>Dan.
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and
ResultSetMetaData.isWritable donot return correct values
Posted by David Van Couvering <Da...@Sun.COM>.
Ok, thanks, that makes sense.
David
Daniel John Debrunner wrote:
> David Van Couvering wrote:
>
>
>>Hi, Mamta, I have actually been trying to review this patch, but this is
>> my first patch review, and I am learning *a lot* about how to set up a
>>clean "drop" of Derby at the revision level you are at, applying and
>>reviewing a patch. I do hope in the future my response time will be
>>better.
>
>
> In general you should be able to apply the patch at the latest (most
> recent) level of the trunk and not care about the specific revision
> level the patch was created at.
>
> If I was committing a patch and there were conflicts at the most recent
> level then most likely I would request the contributor to resolve the
> conflicts and re-submit the patch. Usually the contributor is the best
> person to resolve any conflicts.
>
> Thus as a reviewer, the same approach may be the best, any conflicts
> push the patch back to the contributor and ask them to re-submit.
>
> Dan.
>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable
donot return correct values
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David Van Couvering wrote:
> Hi, Mamta, I have actually been trying to review this patch, but this is
> my first patch review, and I am learning *a lot* about how to set up a
> clean "drop" of Derby at the revision level you are at, applying and
> reviewing a patch. I do hope in the future my response time will be
> better.
In general you should be able to apply the patch at the latest (most
recent) level of the trunk and not care about the specific revision
level the patch was created at.
If I was committing a patch and there were conflicts at the most recent
level then most likely I would request the contributor to resolve the
conflicts and re-submit the patch. Usually the contributor is the best
person to resolve any conflicts.
Thus as a reviewer, the same approach may be the best, any conflicts
push the patch back to the contributor and ask them to re-submit.
Dan.
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and
ResultSetMetaData.isWritable donot return correct values
Posted by David Van Couvering <Da...@Sun.COM>.
Hi, Mamta, I have actually been trying to review this patch, but this is
my first patch review, and I am learning *a lot* about how to set up a
clean "drop" of Derby at the revision level you are at, applying and
reviewing a patch. I do hope in the future my response time will be better.
Thanks,
David
Mamta Satoor wrote:
> Hi,
>
> I am sorry if I sound like a broken record, but please, will someone
> review this? And if no concerns from anyone, will a commiter commit
> it?
>
> thanks,
> Mamta
>
> On 4/27/05, Mamta Satoor <ms...@gmail.com> wrote:
>
>>Hi,
>>
>>I wondered if anyone got a chance to review this patch?
>>
>>thanks,
>>Mamta
>>
>>On 4/24/05, Mamta Satoor <ms...@gmail.com> wrote:
>>
>>>Hi Dan,
>>>
>>>I have a new patch for this bug which also fixes the problem you
>>>brought up with sql select * from a.t as X. The fix for this required
>>>change in impl.sql.compile.FromBaseTable's method genResultColList().
>>>I changed the code such that we set the TableDescriptor on the
>>>ColumnDescriptor instance. This TableDescriptor is later used by
>>>ResultColumn.getTableName to get the base table name of the column. In
>>>addition to that, I changed ColumnReference.getSourceTableName and
>>>ColumnReference.getSourceSchemaName so that they don't look at the
>>>user supplied correlation name (if any) to fetch the base table/schema
>>>name.
>>>
>>>I have also added some test cases for the code changes above in
>>>jdbcapi/resultset.java
>>>
>>>Other than this, the rest of the patch stays the same as what you
>>>tried applying last week.
>>>
>>>I have run the tests and there is no new failure because of my changes.
>>>
>>>svn stat output
>>>M java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java
>>>M java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java
>>>M java\engine\org\apache\derby\impl\sql\compile\CursorNode.java
>>>M java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
>>>M java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java
>>>M java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
>>>M java\engine\org\apache\derby\impl\sql\compile\ValueNode.java
>>>M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
>>>M java\engine\org\apache\derby\impl\sql\GenericColumnDescriptor.java
>>>M java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
>>>M java\engine\org\apache\derby\impl\jdbc\EmbedResultSetMetaData.java
>>>M java\engine\org\apache\derby\iapi\sql\dictionary\ColumnDescriptor.java
>>>M java\engine\org\apache\derby\iapi\sql\ResultColumnDescriptor.java
>>>M java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
>>>M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultset.java
>>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\resultset.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\updatableResultSet.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\resultset.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\resultset.out
>>>
>>>Please commit the patch if there are no further issues,
>>>Mamta
>>>
>>>On 4/22/05, Mamta Satoor <ms...@gmail.com> wrote:
>>>
>>>>Hi Dan,
>>>>
>>>>I did some research into this. You are right that for the sql
>>>>select * from a.t as X
>>>>the existing code will return ABC using both getTableName and
>>>>getSourceTableName. Looking at the history of ColumnReference before
>>>>the code was
>>>>contributed, the getSourceTableName was added to Cloudscape so that
>>>>ResultSetMetaData.getTableName will return the correct value which is
>>>>base table
>>>>name. Seems like over the time, this functionality got broken again.
>>>>
>>>>In my code line, I tried changing ColumnReference.getSourceTableName
>>>>to following
>>>>public String getSourceTableName()
>>>>{
>>>>return ((source != null) ? source.getTableName() : null);
>>>>}
>>>>
>>>>But, that did not solve the problem. The source.getTableName() invokes
>>>>ResultColumn.getTableName which is currently coded as follows
>>>>public String getTableName()
>>>>{
>>>> if (tableName != null)
>>>> {
>>>> return tableName;
>>>> }
>>>> if ((columnDescriptor!=null) &&
>>>> (columnDescriptor.getTableDescriptor() != null))
>>>> {
>>>> return columnDescriptor.getTableDescriptor().getName();
>>>> }
>>>> else
>>>> {
>>>> return expression.getTableName();
>>>> }
>>>>}
>>>>
>>>>In the code above, the first 2 if conditions return false and hence
>>>>expression.getTableName() get called which returns ABC for the sql
>>>>above. And this
>>>>is the problem in my opinion. The 2nd if condition needs to succeed in
>>>>order to get the correct value for table name(currently, the 2nd if
>>>>condition
>>>>returns false because columnDescriptor.getTableDescriptor() returns
>>>>null). columnDescriptor has its table descriptor set to null since it
>>>>got
>>>>instantiated via SYSCOLUMNSRowFactory which passes the uuid for the
>>>>table but not the table descriptor. I tried changing
>>>>ColumnDescriptor's
>>>>2nd constructor(the one which doesn't get table descriptor passed to
>>>>it) to try to get the table descriptor from the uuid by calling
>>>>getDataDictionary.getTableDescriptor(uuid), but it gives me Raw Store
>>>>internal error. I will continue to research but does someone looking
>>>>at this
>>>>explanation have any thoughts on the program flow or issue in general?
>>>>
>>>>thanks,
>>>>Mamta
>>>>
>>>>
>>>>On 4/20/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>>>>
>>>>>The patch applies fine and passes the tests but I need some
>>>>>clarification on some methods in ColumnReference.
>>>>>
>>>>>ColumnReference has these class specific methods
>>>>>
>>>>>getSourceTableName()
>>>>>getSourceSchemaName() [added by this contribution]
>>>>>
>>>>>and because it is a ValueNode it also has
>>>>>
>>>>>getTableName
>>>>>getSchemaName
>>>>>
>>>>>Mamta, can you clarify the difference between the getSource*Name methods
>>>>>and get*Name methods? Eventually as comments in the javadoc for these
>>>>>methods, but some discussion on the list may be useful.
>>>>>
>>>>>I'm worried because most of the bugs around correlation names I think
>>>>>were due to having multiple methods with similar and maybe misleading
>>>>>names but no clear definition of what they returned.
>>>>>
>>>>>In this specific case, my gut reaction from the names of the
>>>>>getSource*Name methods is that they return the actual name of the
>>>>>underlying table the column comes from. But looking the implementation &
>>>>>comments of getTableName and getSourceTableName in ColumnReference.java
>>>>>it seems in this case
>>>>>
>>>>>select * from a.t as X
>>>>>
>>>>>that both methods will return X.
>>>>>
>>>>>Dan.
>>>>>
>>>>>
>>>>
>>>
>>>
>>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Posted by Mamta Satoor <ms...@gmail.com>.
Hi,
Will someone please commit this simple patch for me?
thanks,
Mamta
On 5/16/05, Mamta Satoor <ms...@gmail.com> wrote:
>
> Hi,
> This bug just does not want to call it quit :(
> I just realized that with the last patch, I accidentally overwrote the
> jdk13 specific master with jdk14 output. So, please find attached one file
> update patch which puts the correct master file for jdk13.
> Just a little history. When running say a test with jdk14 or higher, test
> harness checks if there is a master file in
> org.apache.derbyTesting.functionTests.master.jdk14 package for the test,
> if none, then it picks up the master file from
> org.apache.derbyTesting.functionTests.master When the same test is run
> with jdk prior to jdk14, the master will be picked from
> org.apache.derbyTesting.functionTests.master. updatableResultSet.java has
> few tests specific to CLOB, BLOB, Array, Ref etc which are available in
> jdk14 and higher only. These tests are not run when running in jdk13 and
> hence the test needs specific masters for jdk14 and jdk13. Hope this
> explanation is helpful rather than confusing.
> svn stat
> M
> java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
> thanks,
> Mamta
>
> On 5/12/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> >
> > Mamta Satoor wrote:
> >
> > > Hi,
> > >
> > > Here is the patch with some examples in the javadoc.
> > >
> > > thanks,
> > > Mamta
> >
> > Patch applied, 169838, Derby-189 marked fixed.
> >
> > Thanks,
> > Dan.
> >
> >
>
>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Posted by Mamta Satoor <ms...@gmail.com>.
Hi,
This bug just does not want to call it quit :(
I just realized that with the last patch, I accidentally overwrote the
jdk13 specific master with jdk14 output. So, please find attached one file
update patch which puts the correct master file for jdk13.
Just a little history. When running say a test with jdk14 or higher, test
harness checks if there is a master file in
org.apache.derbyTesting.functionTests.master.jdk14 package for the test, if
none, then it picks up the master file from
org.apache.derbyTesting.functionTests.master When the same test is run with
jdk prior to jdk14, the master will be picked from
org.apache.derbyTesting.functionTests.master. updatableResultSet.java has
few tests specific to CLOB, BLOB, Array, Ref etc which are available in
jdk14 and higher only. These tests are not run when running in jdk13 and
hence the test needs specific masters for jdk14 and jdk13. Hope this
explanation is helpful rather than confusing.
svn stat
M
java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
thanks,
Mamta
On 5/12/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>
> Mamta Satoor wrote:
>
> > Hi,
> >
> > Here is the patch with some examples in the javadoc.
> >
> > thanks,
> > Mamta
>
> Patch applied, 169838, Derby-189 marked fixed.
>
> Thanks,
> Dan.
>
>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable
donot return correct values
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Mamta Satoor wrote:
> Hi,
>
> Here is the patch with some examples in the javadoc.
>
> thanks,
> Mamta
Patch applied, 169838, Derby-189 marked fixed.
Thanks,
Dan.
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Posted by Mamta Satoor <ms...@gmail.com>.
Hi,
Here is the patch with some examples in the javadoc.
thanks,
Mamta
On 5/10/05, Mamta Satoor <ms...@gmail.com> wrote:
> Knowing my volatile memory, I think it is best that I take you up on
> your suggestion of adding the explanation and examples in the javadoc.
> I hope to have a patch with these comments by early tomorrow.
>
> thanks,
> Mamta
>
> On 5/10/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> > Mamta Satoor wrote:
> >
> > > Hi Dan,
> > >
> > > Here is another patch with more comments on the getTable/SchemaName
> > > and getSourceTable/SchemaName methods.
> > >
> > > As for your following question
> > > "Then with this patch ColumnReference has a getSchemaName() and a
> > > getSourceSchemaName(). I'm unclear on what the intended behaviour of
> > > each is, and why we need two methods. If getTableName() means return the
> > > "user" name or correlation name, then logically getSchemaName() would
> > > follow the same pattern, but user names or correlation names don't have
> > > schemas."
> > > You are right that there is no way to provide a correlation name for
> > > schema. But a user sql can look like following
> > > select app1.t1.c1, app2.t1.c1 from app1.t1, app2.t1
> > > For this sql, getSchemaName(and getSourceSchemaName) will return app1
> > > for first column and app2 for second column.
> > >
> > > For select t1.c1 from t1, getSchemaName for first column will return
> > > null but getSourceSchemaName will return app (assuming we are in the
> > > schema app).
> > >
> > > Aggregate functions rely on ColumnReference.getSchemaName at generate time.
> >
> > The above comments and examples are really helpful, and would be even
> > more helpful if they were added to the javadoc comments for these
> > methods. :-)
> >
> > A third example would be 'select a.c1 from t1 a'
> >
> > I'll work on committing this patch.
> >
> > Dan.
> >
> >
>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Posted by Mamta Satoor <ms...@gmail.com>.
Knowing my volatile memory, I think it is best that I take you up on
your suggestion of adding the explanation and examples in the javadoc.
I hope to have a patch with these comments by early tomorrow.
thanks,
Mamta
On 5/10/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> Mamta Satoor wrote:
>
> > Hi Dan,
> >
> > Here is another patch with more comments on the getTable/SchemaName
> > and getSourceTable/SchemaName methods.
> >
> > As for your following question
> > "Then with this patch ColumnReference has a getSchemaName() and a
> > getSourceSchemaName(). I'm unclear on what the intended behaviour of
> > each is, and why we need two methods. If getTableName() means return the
> > "user" name or correlation name, then logically getSchemaName() would
> > follow the same pattern, but user names or correlation names don't have
> > schemas."
> > You are right that there is no way to provide a correlation name for
> > schema. But a user sql can look like following
> > select app1.t1.c1, app2.t1.c1 from app1.t1, app2.t1
> > For this sql, getSchemaName(and getSourceSchemaName) will return app1
> > for first column and app2 for second column.
> >
> > For select t1.c1 from t1, getSchemaName for first column will return
> > null but getSourceSchemaName will return app (assuming we are in the
> > schema app).
> >
> > Aggregate functions rely on ColumnReference.getSchemaName at generate time.
>
> The above comments and examples are really helpful, and would be even
> more helpful if they were added to the javadoc comments for these
> methods. :-)
>
> A third example would be 'select a.c1 from t1 a'
>
> I'll work on committing this patch.
>
> Dan.
>
>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable
donot return correct values
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Mamta Satoor wrote:
> Hi Dan,
>
> Here is another patch with more comments on the getTable/SchemaName
> and getSourceTable/SchemaName methods.
>
> As for your following question
> "Then with this patch ColumnReference has a getSchemaName() and a
> getSourceSchemaName(). I'm unclear on what the intended behaviour of
> each is, and why we need two methods. If getTableName() means return the
> "user" name or correlation name, then logically getSchemaName() would
> follow the same pattern, but user names or correlation names don't have
> schemas."
> You are right that there is no way to provide a correlation name for
> schema. But a user sql can look like following
> select app1.t1.c1, app2.t1.c1 from app1.t1, app2.t1
> For this sql, getSchemaName(and getSourceSchemaName) will return app1
> for first column and app2 for second column.
>
> For select t1.c1 from t1, getSchemaName for first column will return
> null but getSourceSchemaName will return app (assuming we are in the
> schema app).
>
> Aggregate functions rely on ColumnReference.getSchemaName at generate time.
The above comments and examples are really helpful, and would be even
more helpful if they were added to the javadoc comments for these
methods. :-)
A third example would be 'select a.c1 from t1 a'
I'll work on committing this patch.
Dan.
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Posted by Mamta Satoor <ms...@gmail.com>.
Hi Dan,
Here is another patch with more comments on the getTable/SchemaName
and getSourceTable/SchemaName methods.
As for your following question
"Then with this patch ColumnReference has a getSchemaName() and a
getSourceSchemaName(). I'm unclear on what the intended behaviour of
each is, and why we need two methods. If getTableName() means return the
"user" name or correlation name, then logically getSchemaName() would
follow the same pattern, but user names or correlation names don't have
schemas."
You are right that there is no way to provide a correlation name for
schema. But a user sql can look like following
select app1.t1.c1, app2.t1.c1 from app1.t1, app2.t1
For this sql, getSchemaName(and getSourceSchemaName) will return app1
for first column and app2 for second column.
For select t1.c1 from t1, getSchemaName for first column will return
null but getSourceSchemaName will return app (assuming we are in the
schema app).
Aggregate functions rely on ColumnReference.getSchemaName at generate time.
svn stat
M java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java
M java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java
M java\engine\org\apache\derby\impl\sql\compile\CursorNode.java
M java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
M java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java
M java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
M java\engine\org\apache\derby\impl\sql\compile\ValueNode.java
M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
M java\engine\org\apache\derby\impl\sql\GenericColumnDescriptor.java
M java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
M java\engine\org\apache\derby\impl\jdbc\EmbedResultSetMetaData.java
M java\engine\org\apache\derby\iapi\sql\dictionary\ColumnDescriptor.java
M java\engine\org\apache\derby\iapi\sql\ResultColumnDescriptor.java
M java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultset.java
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\resultset.out
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\updatableResultSet.out
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\resultset.out
M java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
M java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
M java\testing\org\apache\derbyTesting\functionTests\master\resultset.out
Hope this helps clarify the confusion.
Mamta
On 5/4/05, Satheesh Bandaram <sa...@sourcery.org> wrote:
> I am getting ready to submit this patch.
>
> Satheesh
>
> Mamta Satoor wrote:
>
> Hi David,
I have attached a new patch to take care of the comments from
> your review.
1)Good catch
> about
impl.sql.compile.ResultColumnList.getResultColumnThroughExpression().
It
> is left over code from another solution I was trying to fix the
problem. I
> have taken it out of the review package attached to this
mail.
2)The change
> in ResultColumnDescriptor.java for getSourceSchemaName is
for clarity and
> consistency reasons (similar to getSourceTableName).
With this
change,
> EmbedResultSetMetaData now calls getSourceXXXName for
getTableName and
> getSchemaName. Similarly, in
GenericColumnDescriptor(which implements
> ResultColumnDescriptor), we
have getSourceXXXName to keep the source table
> and source schema name.
3)I have reformatted code and comments to not
> exceed 80 characters.
Also, changed the comments for method
> commonCodeForUpdateableBySql
from .. to /** and */
thanks,
Mamta
On 5/2/05,
> David Van Couvering <Da...@sun.com> wrote:
> Hi, Mamta, this looks good. It built, and I ran as many tests as I
could
> before I had to leave for the day. My God, those tests take a
long time to
> run. But that's a topic for a separate discussion :)
Here are my comments
> and questions...
- What you have looks good and makes sense, but I don't
> know the code
well enough to know if you're missing something. I guess the
> tests help
guarantee that, but someone more familiar with the code taking a
> look
would be great.
- I was curious
> how
impl.sql.compile.ResultColumnList.getResultColumnThroughExpression()
> was
used. In NetBeans I searched for all usages of it and could find none.
> To double-check, I did a full search of the codeline and only found
it where
> it is defined, and no uses. Is there a reason to have this
method if nothing
> uses it?
- in ResultColumnDescriptor.java, why did you change the method
> from
getSchemaName() to getSourceSchemaName()? Is this just to make it
> more
clear what the method is doing?
- A lot of your comments and code seem
> to far exceed 80 characters in
length per line. This makes it hard to read
> in diff output and
text-based editors, and it requires scrolling in IDEs.
> Could you please
limit your source lines to 80 characters?
- The method
> commonCodeForUpdateableBySql in ResultColumnList.java
should have comments
> with /** and */ rather than // It took me a while
in 'vi' to determine this
> was a new method, to the eye it looks like a
continuation of the previous
> method.
David
Mamta Satoor wrote:
> Hi,
I am sorry if I sound like a broken record, but please, will
> someone
review this? And if no concerns from anyone, will a commiter
> commit
it?
thanks,
Mamta
On 4/27/05, Mamta Satoor <ms...@gmail.com>
> wrote:
> Hi,
I wondered if anyone got a chance to review this
> patch?
thanks,
Mamta
On 4/24/05, Mamta Satoor <ms...@gmail.com> wrote:
> Hi Dan,
I have a new patch for this bug which also fixes the problem
> you
brought up with sql select * from a.t as X. The fix for this
> required
change in impl.sql.compile.FromBaseTable's method
> genResultColList().
I changed the code such that we set the TableDescriptor
> on the
ColumnDescriptor instance. This TableDescriptor is later used
> by
ResultColumn.getTableName to get the base table name of the column.
> In
addition to that, I changed
> ColumnReference.getSourceTableName
> and
ColumnReference.getSourceSchemaName so that they don't
> look at the
user supplied correlation name (if any) to fetch the base
> table/schema
name.
I have also added some test cases for the code changes
> above in
jdbcapi/resultset.java
Other than this, the rest of the patch
> stays the same as what you
tried applying last week.
I have run the tests
> and there is no new failure because of my changes.
svn stat output
M
> java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java
M
> java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java
M
> java\engine\org\apache\derby\impl\sql\compile\CursorNode.java
M
> java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
M
> java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java
M
> java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
M
> java\engine\org\apache\derby\impl\sql\compile\ValueNode.java
M
> java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
M
> java\engine\org\apache\derby\impl\sql\GenericColumnDescriptor.java
M
> java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
M
> java\engine\org\apache\derby\impl\jdbc\EmbedResultSetMetaData.java
M
> java\engine\org\apache\derby\iapi\sql\dictionary\ColumnDescriptor.java
M
> java\engine\org\apache\derby\iapi\sql\ResultColumnDescriptor.java
M
> java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
M
> java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultset.java
M
> java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out
M
> java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\resultset.out
M
> java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\updatableResultSet.out
M
> java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\resultset.out
M
> java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
M
> java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
M
> java\testing\org\apache\derbyTesting\functionTests\master\resultset.out
Please
> commit the patch if there are no further issues,
Mamta
On 4/22/05, Mamta
> Satoor <ms...@gmail.com> wrote:
> Hi Dan,
I did some research into this. You are right that for the
> sql
select * from a.t as X
the existing code will return ABC using both
> getTableName and
getSourceTableName. Looking at the history of
> ColumnReference before
the code was
contributed, the getSourceTableName was
> added to Cloudscape so that
ResultSetMetaData.getTableName will return the
> correct value which is
base table
name. Seems like over the time, this
> functionality got broken again.
In my code line, I tried changing
> ColumnReference.getSourceTableName
to following
public
> String getSourceTableName()
{
return ((source != null) ?
> source.getTableName() : null);
}
But, that did not solve the problem. The
> source.getTableName() invokes
ResultColumn.getTableName which is currently
> coded as follows
public String getTableName()
{
if (tableName != null)
{
> return tableName;
}
if ((columnDescriptor!=null) &&
> (columnDescriptor.getTableDescriptor() != null))
{
return
> columnDescriptor.getTableDescriptor().getName();
}
else
{
> return expression.getTableName();
}
}
In the code above, the first 2 if
> conditions return false and hence
expression.getTableName() get called which
> returns ABC for the sql
above. And this
is the problem in my opinion. The
> 2nd if condition needs to succeed in
order to get the correct value for
> table name(currently, the 2nd if
condition
returns false because
> columnDescriptor.getTableDescriptor() returns
null).
> columnDescriptor has its table descriptor set to null since
> it
got
instantiated via SYSCOLUMNSRowFactory which passes the uuid for
> the
table but not the table descriptor. I tried
> changing
ColumnDescriptor's
2nd constructor(the one which doesn't get table
> descriptor passed to
it) to try to get the table descriptor from the uuid by
> calling
getDataDictionary.getTableDescriptor(uuid), but it
> gives me Raw Store
internal error. I will continue to research but does
> someone looking
at this
explanation have any thoughts on the program flow or
> issue in general?
thanks,
Mamta
On 4/20/05, Daniel John Debrunner
> <dj...@debrunners.com> wrote:
> The patch applies fine and passes the tests but I need some
clarification on
> some methods in ColumnReference.
ColumnReference has these class specific
> methods
getSourceTableName()
getSourceSchemaName() [added by this
> contribution]
and because it is a ValueNode it also
> has
getTableName
getSchemaName
Mamta, can you clarify the difference
> between the getSource*Name methods
and get*Name methods? Eventually as
> comments in the javadoc for these
methods, but some discussion on the list
> may be useful.
I'm worried because most of the bugs around correlation
> names I think
were due to having multiple methods with similar and maybe
> misleading
names but no clear definition of what they returned.
In this
> specific case, my gut reaction from the names of the
getSource*Name methods
> is that they return the actual name of the
underlying table the column comes
> from. But looking the implementation &
comments of getTableName and
> getSourceTableName in ColumnReference.java
it seems in this case
select *
> from a.t as X
that both methods will return X.
Dan.
>
> >
> ________________________________
>
Index:
> java/engine/org/apache/derby/impl/sql/compile/ResultColumn.java
===================================================================
---
> java/engine/org/apache/derby/impl/sql/compile/ResultColumn.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/sql/compile/ResultColumn.java
> (working copy)
@@ -85,6 +85,8 @@
String exposedName;
String tableName;
> String sourceTableName;
+ //Used by metadata api
> ResultSetMetaData.getSchemaName to get a column's table's schema.
+ String
> sourceSchemaName;
ValueNode expression;
ColumnDescriptor
> columnDescriptor;
boolean isGenerated;
@@ -215,12 +217,12 @@
return
> exposedName;
}
- public String getSchemaName()
+ public String
> getSchemaName() throws StandardException
{
- if ((columnDescriptor!=null)
> &&
- (columnDescriptor.getTableDescriptor() != null))
+
> if ((columnDescriptor!=null) &&
+
> (columnDescriptor.getTableDescriptor() != null))
return
> columnDescriptor.getTableDescriptor().getSchemaName();
-
> else
+ else
{
if (expression != null)
// REMIND: could look in
> reference, if set.
@@ -236,8 +238,8 @@
{
return tableName;
}
- if
> ((columnDescriptor!=null) &&
-
> (columnDescriptor.getTableDescriptor() != null))
+ if
> ((columnDescriptor!=null) &&
+
> (columnDescriptor.getTableDescriptor() != null))
{
return
> columnDescriptor.getTableDescriptor().getName();
}
@@
> -256,6 +258,14 @@
}
/**
+ * @see
> ResultColumnDescriptor#getSourceSchemaName
+ */
+ public
> String getSourceSchemaName()
+ {
+ return sourceSchemaName;
+ }
+
+ /**
*
> Clear the table name for the underlying ColumnReference.
* See UpdateNode
> for full explaination.
*/
@@ -274,14 +284,14 @@
public
> DataTypeDescriptor getExpressionType()
{
- return (expression == null) ?
+
> return (expression == null) ?
dataTypeServices :
> expression.getTypeServices();
}
public int getColumnPosition()
{
- if
> (columnDescriptor!=null)
+ if (columnDescriptor!=null)
return
> columnDescriptor.getPosition();
else
return virtualColumnId;
@@ -785,6
> +795,7 @@
ColumnReference cr = (ColumnReference) expression;
tableName =
> cr.getTableName();
sourceTableName = cr.getSourceTableName();
+
> sourceSchemaName = cr.getSourceSchemaName();
}
}
@@ -1335,11 +1346,11
> @@
}
/**
- * Tell whether this column is updatable bay a positioned
> update.
+ * Tell whether this column is updatable by a positioned update.
> *
* @return true means this column is updatable
*/
- boolean
> updatableByCursor()
+ public boolean updatableByCursor()
{
return
> updatableByCursor;
}
Index:
> java/engine/org/apache/derby/impl/sql/compile/VirtualColumnNode.java
===================================================================
---
> java/engine/org/apache/derby/impl/sql/compile/VirtualColumnNode.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/sql/compile/VirtualColumnNode.java
> (working copy)
@@ -123,6 +123,40 @@
}
/**
+ * Get the name of the table
> the ResultColumn is in, if any.
+ *
+ * @return A String containing the name
> of the table the Column
+ * is in. If the column is not in a table (i.e. is
> a
+ * derived column), it returns NULL.
+ */
+ public String
> getTableName()
+ {
+ return ( ( sourceColumn != null) ?
> sourceColumn.getTableName() : null );
+ }
+
+ /**
+ * Get the name of the
> schema the ResultColumn's table is in, if any.
+ *
+ * @return A String
> containing the name of the schema for the Column's table.
+ * If the column
> is not in a schema (i.e. derived column), it returns NULL.
+ */
+ public
> String getSchemaName() throws StandardException
+ {
+ return ( (
> sourceColumn != null) ? sourceColumn.getSchemaName() : null );
+ }
+
+ /**
+
> * Return whether or not the ResultColumn is wirtable by a positioned
> update.
+ *
+ * @return TRUE, if the column is a base column of a table and
> is
+ * writable by a positioned update.
+ */
+ public boolean
> updatableByCursor()
+ {
+ return ((sourceColumn != null) ?
> sourceColumn.updatableByCursor() : false);
+ }
+
+ /**
* Return the
> ResultColumn that is the source of this VirtualColumnNode.
*
* @return
> ResultSetNode
Index:
> java/engine/org/apache/derby/impl/sql/compile/CursorNode.java
===================================================================
---
> java/engine/org/apache/derby/impl/sql/compile/CursorNode.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/sql/compile/CursorNode.java
> (working copy)
@@ -295,7 +295,7 @@
if (updateMode == READ_ONLY)
> updatableColumns = null; // don't need them any more
}
-
+
// bind the
> update columns
if (updateMode == UPDATE)
{
@@ -308,6 +308,11 @@
if
> (updateTable instanceof FromTable)
{
((FromTable)
> updateTable).markUpdatableByCursor(updatableColumns);
+
> //make sure that alongwith the FromTable, we keep other ResultSetLists
+
> //in correct state too. ResultSetMetaData.isWritable looks at this to
+
> //return the correct value.
+
> resultSet.getResultColumns().markColumnsInSelectListUpdatableByCursor(
+
> updatableColumns);
}
}
Index:
> java/engine/org/apache/derby/impl/sql/compile/FromBaseTable.java
===================================================================
---
> java/engine/org/apache/derby/impl/sql/compile/FromBaseTable.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/sql/compile/FromBaseTable.java
> (working copy)
@@ -3459,6 +3459,12 @@
{
/* Build a
> ResultColumn/BaseColumnNode pair for the column */
colDesc =
> (ColumnDescriptor) cdl.elementAt(index);
+ //A ColumnDescriptor instantiated
> through SYSCOLUMNSRowFactory only has
+ //the uuid set on it and no table
> descriptor set on it. Since we know here
+ //that this columnDescriptor is
> tied to tableDescriptor, set it so using
+ //setTableDescriptor method.
> ColumnDescriptor's table descriptor is used
+ //to get
> ResultSetMetaData.getTableName & ResultSetMetaData.getSchemaName
+
> colDesc.setTableDescriptor(tableDescriptor);
valueNode = (ValueNode)
> getNodeFactory().getNode(
C_NodeTypes.BASE_COLUMN_NODE,
Index:
> java/engine/org/apache/derby/impl/sql/compile/BaseColumnNode.java
===================================================================
---
> java/engine/org/apache/derby/impl/sql/compile/BaseColumnNode.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/sql/compile/BaseColumnNode.java
> (working copy)
@@ -122,6 +122,16 @@
}
/**
+ * Get the schema name for
> this column's table
+ *
+ * @return The schema name for this column's
> table
+ */
+ public String getSchemaName() throws StandardException
+ {
+
> return ( ( tableName != null) ? tableName.getSchemaName() : null );
+ }
+
+
> /**
* Do the code generation for this node. Should never be called.
*
*
> @param acb The ExpressionClassBuilder for the class being built
Index:
> java/engine/org/apache/derby/impl/sql/compile/ColumnReference.java
===================================================================
---
> java/engine/org/apache/derby/impl/sql/compile/ColumnReference.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/sql/compile/ColumnReference.java
> (working copy)
@@ -502,17 +502,38 @@
/**
* Get the name of the table this
> column comes from.
*
- * @return The name of the table that this column
> comes from.
+ * @return The name of the table that this column comes from.
> * Null if not a ColumnReference.
*/
public String getSourceTableName()
> {
- return ( ( tableName != null) ? tableName.getTableName() :
- ((source
> != null) ? source.getTableName() : null));
+ return ((source != null) ?
> source.getTableName() : null);
}
/**
+ * Get the name of the schema for
> the Column's table, if any.
+ *
+ * @return A String containing the name of
> the schema of the Column's table.
+ * If the column is not in a schema (i.e.
> is a derived column), it returns NULL.
+ */
+ public String
> getSourceSchemaName() throws StandardException
+ {
+ return ((source !=
> null) ? source.getSchemaName() : null);
+ }
+
+ /**
+ * Is the column
> wirtable by the cursor or not. (ie, is it in the list of FOR UPDATE columns
> list)
+ *
+ * @return TRUE, if the column is a base column of a table and is
>
+ * writable by cursor.
+ */
+ public boolean updatableByCursor()
+ {
+
> return ((source != null) ? source.updatableByCursor() : false);
+ }
+
+ /**
> Return the table name as the node it is.
@return the column's table name.
> */
Index:
> java/engine/org/apache/derby/impl/sql/compile/ValueNode.java
===================================================================
---
> java/engine/org/apache/derby/impl/sql/compile/ValueNode.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/sql/compile/ValueNode.java
> (working copy)
@@ -670,13 +670,13 @@
*
* @return the default schema name
> for an expression -- null
*/
- public String getSchemaName()
+ public
> String getSchemaName() throws StandardException
{
return null;
}
/**
-
> * @return the default schema name for an expression -- null
+ * @return the
> default table name for an expression -- null
*/
public String
> getTableName()
{
@@ -684,6 +684,14 @@
}
/**
+ * @return the default
> updatability for an expression - false
+ */
+ public boolean
> updatableByCursor()
+ {
+ return false;
+ }
+
+ /**
* This is null so that
> the caller will substitute in the resultset generated
* name as needed.
> *
Index:
> java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java
===================================================================
---
> java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java
> (working copy)
@@ -2437,7 +2437,7 @@
}
/**
- * Mark all the columns in
> this list as updatable by a positioned update
+ * Mark all the (base)
> columns in this list as updatable by a positioned update
* statement. This
> is necessary
* for positioned update statements, because we expand the
> column list
* to include all the columns in the base table, and we need to
> be able
@@ -2453,7 +2453,9 @@
for (int index = 0; index < size; index++)
> {
- ((ResultColumn)
> elementAt(index)).markUpdatableByCursor();
+ //determine if
> the column is a base column and not a derived column
+ if (((ResultColumn)
> elementAt(index)).getSourceTableName() != null)
+
> ((ResultColumn) elementAt(index)).markUpdatableByCursor();
> }
}
@@ -2630,17 +2632,33 @@
}
/**
- * Mark as updatable all the
> columns in this result column list
- * that match the columns in the given
> update column list
+ * Mark all the columns in the select sql that this
> result column list represents
+ * as updatable if they match the columns in
> the given update column list.
*
* @param updateColumns A Vector
> representing the columns
* to be updated.
*/
- void
> markUpdatableByCursor(Vector updateColumns)
+ void
> markColumnsInSelectListUpdatableByCursor(Vector
> updateColumns)
{
+
> commonCodeForUpdatableByCursor(updateColumns, true);
+
> }
+
+ /**
+ * dealingWithSelectResultColumnList true means
> we are dealing with
+ * ResultColumnList for a select sql. When dealing with
> ResultColumnList for
+ * select sql, it is possible that not all the
> updatable columns are
+ * projected in the select column list and hence it
> is possible that we may
+ * not find the column to be updated in the
> ResultColumnList and that is why
+ * special handling is required when
> dealingWithSelectResultColumnList is true.
+ * eg select
> c11, c13 from t1 for update of c11, c12
+ * In the eg above, we will find
> updatable column c11 in the select column
+ * list but we will not find
> updatable column c12 in the select column list
+ */
+ private void
> commonCodeForUpdatableByCursor(Vector updateColumns,
> boolean dealingWithSelectResultColumnList)
+ {
/*
- ** If
> there is no update column list, or the list is empty,
- ** it means all the
> columns are updatable.
+ ** If there is no update column list, or the list
> is empty, then it means that
+ ** all the columns which have a base table
> associated with them are updatable.
*/
if ( (updateColumns == null) ||
> (updateColumns.size() == 0) )
{
@@ -2654,26 +2672,39 @@
for (int index =
> 0; index < ucSize; index++)
{
- columnName = (String)
> updateColumns.elementAt(index);
+ columnName = (String)
> updateColumns.elementAt(index);
resultColumn =
> getResultColumn(columnName);
-
if (SanityManager.DEBUG)
{
- if
> (resultColumn == null)
+ if (resultColumn == null &&
> !dealingWithSelectResultColumnList)
{
-
> SanityManager.THROWASSERT(
- "No result column found with name " +
+
> SanityManager.THROWASSERT("No result column found with name " +
> columnName);
}
}
-
+ //Following if means the column specified in FOR
> UPDATE clause is not
+ //part of the select list
+ if (resultColumn == null
> && dealingWithSelectResultColumnList)
+ continue;
> resultColumn.markUpdatableByCursor();
}
}
}
/**
+ *
> Mark as updatable all the columns in this result column list
+ * that match
> the columns in the given update column list
+ *
+ * @param updateColumns A
> Vector representing the columns
+ * to be updated.
+ */
+ void
> markUpdatableByCursor(Vector updateColumns)
+ {
+
> commonCodeForUpdatableByCursor(updateColumns, false);
+
> }
+
+ /**
* Returns true if the given column position is for a column that
> will
* be or could be updated by the positioned update of a cursor.
> *
Index:
> java/engine/org/apache/derby/impl/sql/GenericColumnDescriptor.java
===================================================================
---
> java/engine/org/apache/derby/impl/sql/GenericColumnDescriptor.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/sql/GenericColumnDescriptor.java
> (working copy)
@@ -66,6 +66,7 @@
private int columnPos;
private
> DataTypeDescriptor type;
private boolean isAutoincrement;
+ private boolean
> updatableByCursor;
/**
* Niladic constructor for Formatable
@@ -92,10
> +93,11 @@
{
name = rcd.getName();
tableName = rcd.getSourceTableName();
-
> schemaName = rcd.getSchemaName();
+ schemaName = rcd.getSourceSchemaName();
> columnPos = rcd.getColumnPosition();
type = rcd.getType();
isAutoincrement
> = rcd.isAutoincrement();
+ updatableByCursor = rcd.updatableByCursor();
}
>
/**
@@ -127,7 +129,7 @@
* is in. If the column is not in a schema (i.e.
> is a
* derived column), it returns NULL.
*/
- public String
> getSchemaName()
+ public String getSourceSchemaName()
{
return
> schemaName;
}
@@ -161,6 +163,11 @@
return isAutoincrement;
}
+ public
> boolean updatableByCursor()
+ {
+ return updatableByCursor;
+ }
+
> //////////////////////////////////////////////
//
//
> FORMATABLE
@@ -182,6 +189,7 @@
fh.putInt("columnPos", columnPos);
> fh.put("type", type);
fh.putBoolean("isAutoincrement", isAutoincrement);
+
> fh.putBoolean("updatableByCursor", updatableByCursor);
> out.writeObject(fh);
return;
}
@@ -205,6 +213,7 @@
columnPos =
> fh.getInt("columnPos");
type =
> (DataTypeDescriptor)fh.get("type");
isAutoincrement =
> fh.getBoolean("isAutoincrement");
+ updatableByCursor =
> fh.getBoolean("updatableByCursor");
}
/**
Index:
> java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
===================================================================
---
> java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
> (working copy)
@@ -2043,11 +2043,19 @@
//1)Make sure for updateXXX methods,
> the column position is not out of range
ResultDescription rd =
> theResults.getResultDescription();
if (columnIndex < 1 || columnIndex >
> rd.getColumnCount())
- throw
> Util.generateCsSQLException(SQLState.LANG_INVALID_COLUMN_POSITION,
> new Integer(columnIndex), String.valueOf(rd.getColumnCount()));
+ throw
> Util.generateCsSQLException(SQLState.LANG_INVALID_COLUMN_POSITION,
+
> new Integer(columnIndex), String.valueOf(rd.getColumnCount()));
//2)Make
> sure the column corresponds to a column in the base table and it is not a
> derived column
if
> (rd.getColumnDescriptor(columnIndex).getSourceTableName()
> == null)
- throw
> Util.generateCsSQLException(SQLState.COLUMN_NOT_FROM_BASE_TABLE,
> methodName);
+ throw
> Util.generateCsSQLException(SQLState.COLUMN_NOT_FROM_BASE_TABLE,
+
> methodName);
+
+ //3)If column not updatable then throw an exception
+ if
> (!getMetaData().isWritable(columnIndex))
+ throw
> Util.generateCsSQLException(SQLState.LANG_COLUMN_NOT_UPDATABLE_IN_CURSOR,
+
> theResults.getResultDescription().getColumnDescriptor(columnIndex).getName(),
+
> getCursorName());
}
//do following few checks before accepting updatable
> resultset api
@@ -3153,6 +3161,8 @@
boolean foundOneColumnAlready = false;
> StringBuffer updateWhereCurrentOfSQL = new StringBuffer("UPDATE ");
> CursorActivation activation =
> getEmbedConnection().getLanguageConnection().lookupCursorActivation(getCursorName());
+
+
> ExecCursorTableReference targetTable =
> activation.getPreparedStatement().getTargetTable();
> updateWhereCurrentOfSQL.append(getFullBaseTableName(targetTable));//got
> the underlying (schema.)table name
updateWhereCurrentOfSQL.append(" SET
> ");
Index:
> java/engine/org/apache/derby/impl/jdbc/EmbedResultSetMetaData.java
===================================================================
---
> java/engine/org/apache/derby/impl/jdbc/EmbedResultSetMetaData.java
> (revision 167913)
+++
> java/engine/org/apache/derby/impl/jdbc/EmbedResultSetMetaData.java
> (working copy)
@@ -204,7 +204,7 @@
public String getSchemaName(int column)
> throws SQLException {
ResultColumnDescriptor cd = columnInfo[column - 1];
>
- String s = cd.getSchemaName();
+ String s = cd.getSourceSchemaName();
//
> database returns null when no schema name to differentiate from empty name
> return (s==null? "" : s);
}
@@ -308,9 +308,7 @@
*/
public boolean
> isWritable(int column) throws SQLException {
validColumnNumber(column);
-
-
> // we just don't know if it is a base table column or not
- return false;
+
> return columnInfo[column - 1].updatableByCursor();
}
/**
Index:
> java/engine/org/apache/derby/iapi/sql/dictionary/ColumnDescriptor.java
===================================================================
---
> java/engine/org/apache/derby/iapi/sql/dictionary/ColumnDescriptor.java
> (revision 167913)
+++
> java/engine/org/apache/derby/iapi/sql/dictionary/ColumnDescriptor.java
> (working copy)
@@ -104,7 +104,7 @@
this.table = table;
this.uuid =
> table.getUUID();
}
-
+
if (SanityManager.DEBUG)
{
if (autoinc)
@@
> -136,7 +136,7 @@
* (null if no default)
* @param columnDefaultInfo The
> default info for the column.
* @param uuid A uuid for the object that this
> column
- * is in.
+ * is in.
* @param defaultUUID The UUID for the
> default, if any.
* @param autoincStart Start value for an autoincrement
> column.
* @param autoincInc Increment for autoincrement column
@@ -145,8
> +145,8 @@
public ColumnDescriptor(String columnName, int columnPosition,
> DataTypeDescriptor columnType, DataValueDescriptor columnDefault,
> DefaultInfo columnDefaultInfo,
- UUID uuid,
- UUID defaultUUID,
+ UUID
> uuid,
+ UUID defaultUUID,
long autoincStart, long autoincInc, boolean
> autoinc)
{
@@ -220,7 +220,7 @@
}
/**
- * Sets the the column name in
> case of rename column.
+ * Sets the column name in case of rename column.
> *
* @param newColumnName The new column name.
*/
@@ -230,6 +230,16 @@
}
>
/**
+ * Sets the table descriptor for the column.
+ *
+ * @param
> tableDescriptor The table descriptor for this column
+ */
+ public void
> setTableDescriptor(TableDescriptor tableDescriptor)
+ {
+
> this.table = tableDescriptor;
+ }
+
+ /**
* Get the ordinal position of the
> column (1 based)
*
* @return The ordinal position of the column.
@@ -326,6
> +336,10 @@
{
return (autoincInc != 0);
}
+ public boolean
> updatableByCursor()
+ {
+ return false;
+ }
/**
* Get the start value of
> an autoincrement column
Index:
> java/engine/org/apache/derby/iapi/sql/ResultColumnDescriptor.java
===================================================================
---
> java/engine/org/apache/derby/iapi/sql/ResultColumnDescriptor.java
> (revision 167913)
+++
> java/engine/org/apache/derby/iapi/sql/ResultColumnDescriptor.java
> (working copy)
@@ -47,24 +47,32 @@
String getName();
/**
- * Get the
> name of the schema the Column is in, if any.
+ * Get the name of the schema
> the Column's table is in, if any.
*
- * @return A String containing the
> name of the schema the Column
- * is in. If the column is not in a schema
> (i.e. is a
+ * @return A String containing the name of the schema to which
> Column's
+ * table belongs. If the column is not from a table (i.e. is a
*
> derived column), it returns NULL.
*/
- String getSchemaName();
+ String
> getSourceSchemaName();
/**
* Get the name of the table the Column is in,
> if any.
*
- * @return A String containing the name of the table the
> Column
+ * @return A String containing the name of the table of the Column
> * is in. If the column is not in a table (i.e. is a
* derived column), it
> returns NULL.
*/
String getSourceTableName();
/**
+ * Return true if
> the column is wirtable by a positioned update.
+ *
+ * @return TRUE, if the
> column is a base column of a table and is
+ * writable by a positioned
> update.
+ */
+ boolean updatableByCursor();
+
+ /**
* Get the position of
> the Column.
* NOTE - position is 1-based.
*
Index:
> java/testing/org/apache/derbyTesting/functionTests/tests/lang/updatableResultSet.java
===================================================================
---
> java/testing/org/apache/derbyTesting/functionTests/tests/lang/updatableResultSet.java
> (revision 167913)
+++
> java/testing/org/apache/derbyTesting/functionTests/tests/lang/updatableResultSet.java
> (working copy)
@@ -33,8 +33,8 @@
import org.apache.derby.tools.ij;
> import org.apache.derby.tools.JDBCDisplayUtil;
+import
> org.apache.derby.iapi.services.info.JVMInfo;
import
> org.apache.derbyTesting.functionTests.util.TestUtil;
-import
> org.apache.derby.iapi.services.info.JVMInfo;
import
> java.math.BigDecimal;
import java.sql.Array;
@@ -154,7 +154,7 @@
//I
> have constructed following table based on if combination of datatype and
> updateXXX method would work or not.
- public static final String[][]
> updateXXXRulesTable = {
+ public static final String[][]
> updateXXXRulesTableForEmbedded = {
// Types. u u u u u u u u u u u u u u
> u u u u u u u
// p p p p p p p p p p p p p p p p p p p p p
@@ -194,8
> +194,51 @@
/* 15 TIMESTAMP */ { "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "PASS", "PASS", "PASS", "ERROR", "ERROR", "PASS", "ERROR", "ERROR"
> },
/* 16 BLOB */ { "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "ERROR", "ERROR", "PASS", "PASS", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "ERROR", "PASS", "ERROR", "ERROR" },
- };
+ };
>
+ //I have constructed following table for network server based on if
> combination of datatype and updateXXX method would work or not.
+ public
> static final String[][] updateXXXRulesTableForNetworkServer
> = {
+
+ // Types. u u u u u u u u u u u u u u u u u u u u u
+ // p p p p p p
> p p p p p p p p p p p p p p p
+ // d d d d d d d d d d d d d d d d d d d d
> d
+ // a a a a a a a a a a a a a a a a a a a a a
+ // t t t t t t t t t t t
> t t t t t t t t t t
+ // e e e e e e e e e e e e e e e e e e e e e
+ // S I
> L B F D S A C B B B C D T T B B N A R
+ // h n o i l o t s h y y i l a i i l
> o u r e
+ // o t n g o u r c a t t n o t m m o o l r f
+ // r g D a b i i r
> e e a b e e e b l l a
+ // t e t l n i c s r s e y
+ // c e g S t y t a
+ //
> i t e S a n
+ // m r r t m
+ // a e S r p
+ // l a t e
+ // m r a
+ // e m
+
> // a
+ // m
+/* 0 SMALLINT */ { "PASS", "PASS", "PASS", "PASS", "PASS",
> "PASS", "ERROR", "ERROR", "ERROR", "PASS", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "ERROR", "ERROR", "PASS", "PASS", "ERROR", "ERROR" },
+/*
> 1 INTEGER */ { "PASS", "PASS", "PASS", "PASS", "PASS", "PASS", "ERROR",
> "ERROR", "ERROR", "PASS", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "PASS", "ERROR", "ERROR" },
+/* 2 BIGINT */ {
> "PASS", "PASS", "PASS", "PASS", "PASS", "PASS", "ERROR", "ERROR", "ERROR",
> "PASS", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR",
> "PASS", "PASS", "ERROR", "ERROR" },
+/* 3 DECIMAL */ { "PASS", "PASS",
> "PASS", "PASS", "PASS", "PASS", "ERROR", "ERROR", "ERROR", "PASS", "ERROR",
> "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "PASS", "PASS",
> "ERROR", "ERROR" },
+/* 4 REAL */ { "PASS", "PASS", "PASS", "PASS", "PASS",
> "PASS", "PASS", "ERROR", "ERROR", "PASS", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "ERROR", "ERROR", "PASS", "PASS", "ERROR", "ERROR" },
+/*
> 5 DOUBLE */ { "PASS", "PASS", "PASS", "PASS", "PASS", "PASS", "PASS",
> "ERROR", "ERROR", "PASS", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "PASS", "ERROR", "ERROR" },
+/* 6 CHAR */ {
> "PASS", "PASS", "PASS", "PASS", "PASS", "PASS", "PASS", "PASS", "PASS",
> "PASS", "ERROR", "ERROR", "ERROR", "PASS", "PASS", "PASS", "ERROR", "PASS",
> "PASS", "ERROR", "ERROR" },
+/* 7 VARCHAR */ { "PASS", "PASS", "PASS",
> "PASS", "PASS", "PASS", "PASS", "PASS", "PASS", "PASS", "ERROR", "ERROR",
> "ERROR", "PASS", "PASS", "PASS", "ERROR", "PASS", "PASS", "ERROR", "ERROR"
> },
+/* 8 LONGVARCHAR */ { "PASS", "PASS", "PASS", "PASS", "PASS", "PASS",
> "PASS", "PASS", "PASS", "PASS", "ERROR", "ERROR", "ERROR", "PASS", "PASS",
> "PASS", "ERROR", "PASS", "PASS", "ERROR", "ERROR" },
+/* 9 CHAR FOR BIT */ {
> "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "PASS", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "ERROR", "ERROR" },
+/* 10 VARCH. BIT */ {
> "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "PASS", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "ERROR", "ERROR" },
+/* 11 LONGVAR. BIT */ {
> "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "PASS", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "ERROR", "ERROR" },
+/* 12 CLOB */ { "ERROR",
> "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "PASS", "PASS", "PASS",
> "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "PASS", "ERROR", "ERROR" },
+/* 13 DATE */ { "ERROR", "ERROR",
> "ERROR", "ERROR", "ERROR", "ERROR", "PASS", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "ERROR", "PASS", "ERROR", "PASS", "ERROR", "ERROR",
> "PASS", "ERROR", "ERROR" },
+/* 14 TIME */ { "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "ERROR", "PASS", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "ERROR", "PASS", "PASS", "ERROR", "ERROR", "PASS",
> "ERROR", "ERROR" },
+/* 15 TIMESTAMP */ { "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "ERROR", "PASS", "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "PASS", "ERROR", "PASS", "ERROR", "ERROR", "PASS",
> "ERROR", "ERROR" },
+/* 16 BLOB */ { "ERROR", "ERROR", "ERROR", "ERROR",
> "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "PASS", "PASS",
> "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "PASS", "ERROR",
> "ERROR" },
+
+ };
+
public static void main(String[] args) {
> System.out.println("Start testing delete and update using JDBC2.0 updateable
> resultset apis");
@@ -256,7 +299,7 @@
}
conn.clearWarnings();
> System.out.println("requested TYPE_SCROLL_SENSITIVE, CONCUR_UPDATABLE but
> that is not supported");
- System.out.println("Jira issue Derby-154 : When
> client connects to Network Server using JCC, it incorrectly shows support
> for scroll sensitive updatable resultsets");
+ System.out.println("Jira
> issue Derby-154 : When client connects to Network Server using JCC, it
> incorrectly shows support for scroll sensitive updatable resultsets");
> System.out.println("Make sure that we got TYPE_SCROLL_INSENSITIVE? " +
> (stmt.getResultSetType() ==
> ResultSet.TYPE_SCROLL_INSENSITIVE));
> System.out.println("Make sure that we got CONCUR_READ_ONLY? " +
> (stmt.getResultSetConcurrency() == ResultSet.CONCUR_READ_ONLY));
> System.out.println("JDBC 2.0 updatable resultset api will fail on this
> resultset because this is not an updatable resultset");
@@ -334,6 +377,7 @@
> //have to close the resultset because by default, resultsets are held open
> over commit
rs.close();
+
System.out.println("Negative Test5 - request
> updatable resultset for sql with no FOR UPDATE clause");
stmt =
> conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_UPDATABLE);
rs = stmt.executeQuery("select * from
> t1");//notice that we forgot to give mandatory FOR UPDATE clause for
> updatable resultset
@@ -357,8 +401,6 @@
System.out.println("SQL State : " +
> e.getSQLState());
System.out.println("Got expected exception " +
> e.getMessage());
}
- //have to close the resultset because by default,
> resultsets are held open over commit
- rs.close();
System.out.println("Now
> attempting to send a updateRow on a sql with no FOR UPDATE clause.");
try
> {
rs.updateRow();
@@ -369,10 +411,15 @@
System.out.println("Got expected
> exception " + e.getMessage());
}
+ //have to close the resultset because
> by default, resultsets are held open over commit
+ rs.close();
+
> System.out.println("Negative Test6 - request updatable resultset for sql
> with FOR READ ONLY clause");
stmt =
> conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_UPDATABLE);
rs = stmt.executeQuery("select * from t1 FOR
> READ ONLY");
System.out.println("Make sure that we got CONCUR_READ_ONLY? "
> + (rs.getConcurrency() == ResultSet.CONCUR_READ_ONLY));
+
> System.out.println("Jira issue Derby-159 : Warnings raised by Derby are not
> getting passed to the Client in Network Server Mode");
+
> System.out.println("Will see the warnings in embedded mode only");
warnings
> = rs.getWarnings();
while (warnings != null)
{
@@ -402,10 +449,9 @@
> //have to close the resultset because by default, resultsets are held open
> over commit
rs.close();
- if (TestUtil.isEmbeddedFramework()) {
> System.out.println("Negative Test7 - attempt to deleteRow & updateRow on
> updatable resultset when the resultset is not positioned on a row");
stmt =
> conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_UPDATABLE);
- rs = stmt.executeQuery("SELECT 1, 2 FROM t1
> FOR UPDATE");
+ rs = stmt.executeQuery("SELECT * FROM t1 FOR UPDATE");
> System.out.println("Make sure that we got CONCUR_UPDATABLE? " +
> (rs.getConcurrency() == ResultSet.CONCUR_UPDATABLE));
> System.out.println("Now attempt a deleteRow without first doing next on the
> resultset.");
try {
@@ -417,9 +463,14 @@
System.out.println("Got expected
> exception " + e.getMessage());
}
System.out.println("Now attempt a
> updateRow without first doing next on the resultset.");
+
> System.out.println("In embedded mode, updateRow will check if it is on a row
> or not even though no changes have been made to the row using updateXXX");
+
> System.out.println("In Network Server mode, if no updateXXX were issued
> before updateRow, then updateRow is a no-op and doesn't check if it is on a
> row or not");
try {
rs.updateRow();
- System.out.println("FAIL!!!
> updateRow should have failed because resultset is not on a row");
+ if
> (TestUtil.isEmbeddedFramework())
+ System.out.println("FAIL!!! In embedded
> mode, this updateRow should have failed because resultset is not on a
> row");
+ else
+ System.out.println("PASS!!! In Network Server mode, this
> updateRow is a no-op because no updateXXX were issued before the
> updateRow");
}
catch (SQLException e) {
System.out.println("SQL State : "
> + e.getSQLState());
@@ -448,7 +499,7 @@
System.out.println("Negative
> Test8 - attempt deleteRow & updateRow on updatable resultset after closing
> the resultset");
stmt = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_UPDATABLE);
- rs = stmt.executeQuery("SELECT 1, 2 FROM t1
> FOR UPDATE");
+ rs = stmt.executeQuery("SELECT * FROM t1 FOR UPDATE");
> System.out.println("Make sure that we got CONCUR_UPDATABLE? " +
> (rs.getConcurrency() == ResultSet.CONCUR_UPDATABLE));
rs.next();
> rs.close();
@@ -503,8 +554,9 @@
System.out.println("Negative Test12 -
> With autocommit on, attempt to drop a table when there is an open updatable
> resultset on it");
stmt = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_UPDATABLE);
- rs = stmt.executeQuery("SELECT 1, 2 FROM t1
> FOR UPDATE");
+ rs = stmt.executeQuery("SELECT c1 FROM t1 FOR UPDATE");
> rs.next();
+ rs.updateInt(1,123);
System.out.println("Opened an updatable
> resultset. Now trying to drop that table through another Statement");
stmt1
> = conn.createStatement();
try {
@@ -535,7 +587,7 @@
> System.out.println("Negative Test13 - foreign key constraint failure will
> cause deleteRow to fail");
stmt =
> conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_UPDATABLE);
- rs = stmt.executeQuery("SELECT 1, 2 FROM
> tableWithPrimaryKey FOR UPDATE");
+ rs = stmt.executeQuery("SELECT * FROM
> tableWithPrimaryKey FOR UPDATE");
rs.next();
try {
rs.deleteRow();
@@
> -548,6 +600,8 @@
System.out.println("Since autocommit is on, the constraint
> exception resulted in a runtime rollback causing updatable resultset object
> to close");
try {
rs.next();
+ if (TestUtil.isNetFramework())
+
> System.out.println("Jira entry Derby-160 : for Network Server because next
> should have failed");
System.out.println("FAIL!!! next should have failed
> because foreign key constraint failure resulted in a runtime rollback");
}
> catch (SQLException e) {
@@ -572,6 +626,8 @@
System.out.println("Since
> autocommit is on, the constraint exception resulted in a runtime rollback
> causing updatable resultset object to close");
try {
rs.next();
+ if
> (TestUtil.isNetFramework())
+ System.out.println("Jira entry Derby-160 : for
> Network Server because next should have failed");
> System.out.println("FAIL!!! next should have failed because foreign key
> constraint failure resulted in a runtime rollback");
}
catch (SQLException
> e) {
@@ -581,7 +637,7 @@
System.out.println("Negative Test15 - Can't call
> updateXXX methods on columns that do not correspond to a column in the
> table");
stmt = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_UPDATABLE);
- rs = stmt.executeQuery("SELECT 1, 2 FROM
> tableWithPrimaryKey FOR UPDATE");
+ rs = stmt.executeQuery("SELECT 1, 2 FROM
> t1 FOR UPDATE");
rs.next();
try {
rs.updateInt(1,22);
@@ -623,13 +679,17
> @@
System.out.println("column 1 on this row before deleteRow is " +
> rs.getInt(1));
System.out.println("column 2 on this row before deleteRow is
> " + rs.getString(2));
rs.deleteRow();
- System.out.println("Since after
> deleteRow(), ResultSet is positioned before the next row, getXXX will
> fail");
+ System.out.println("Since after deleteRow(), in embedded mode,
> ResultSet is positioned before the next row, getXXX will fail");
+
> System.out.println("In Network Server mode, the ResultSet stays on the
> deleted row after deleteRow and hence no error for getXXX");
try {
> System.out.println("column 1 on this deleted row is " + rs.getInt(1));
}
> catch (SQLException e) {
- System.out.println("SQL State : " +
> e.getSQLState());
- System.out.println("Got expected exception " +
> e.getMessage());
+ if (TestUtil.isEmbeddedFramework()) {
+
> System.out.println("SQL State : " + e.getSQLState());
+
> System.out.println("Got expected exception " + e.getMessage());
+ } else
+
> System.out.println("Got unexpected exception " + e.getMessage());
}
> System.out.println("calling deleteRow again w/o first positioning the
> ResultSet on the next row will fail");
try {
@@ -647,6 +707,7 @@
//have to
> close the resultset because by default, resultsets are held open over
> commit
rs.close();
+ if (TestUtil.isEmbeddedFramework()) {
> System.out.println("Positive Test1b - request updatable resultset for
> forward only type resultset");
reloadData();
stmt =
> conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_UPDATABLE);
@@ -664,7 +725,8 @@
System.out.println("column
> 2 on this row before updateString is " + rs.getString(2));
> System.out.println("now updateRow on the row");
rs.updateRow();
-
> System.out.println("Since after updateRow(), ResultSet is positioned before
> the next row, getXXX will fail");
+ System.out.println("Since after
> updateRow(), in embedded mode, ResultSet is positioned before the next row,
> getXXX will fail");
+ System.out.println("In Network Server mode, the
> ResultSet stays on the updated row after updateRow and hence no error for
> getXXX");
try {
System.out.println("column 1 on this updateRow row is " +
> rs.getInt(1));
}
@@ -975,19 +1037,56 @@
reloadData();
rs =
> stmt.executeQuery("SELECT c1, c2 FROM t1 abcde FOR UPDATE of c1");
> rs.next();
- rs.updateString(2,"bbbb");
try {
- rs.updateRow();
-
> System.out.println("FAIL!!! updateRow should have failed");
+
> rs.updateString(2,"bbbb");
+ System.out.println("FAIL!!! updateString on
> readonly column should have failed");
}
catch (SQLException e) {
> System.out.println("SQL State : " + e.getSQLState());
> System.out.println("Got expected exception " + e.getMessage());
}
+
> System.out.println("attempt to get an updatable resultset using correlation
> name for an readonly column. It should work");
+ System.out.println("The sql
> is SELECT c1, c2 as col2 FROM t1 abcde FOR UPDATE of c1");
+ rs =
> stmt.executeQuery("SELECT c1, c2 as col2 FROM t1 abcde FOR UPDATE of c1");
+
> rs.next();
+ rs.updateInt(1,11);
+ rs.updateRow();
rs.close();
> System.out.println("Table t1 after updateRow has following rows");
> dumpRS(stmt.executeQuery("select * from t1"));
+
> System.out.println("Positive Test9c - try to updateXXX on a readonly column.
> Should get error");
+ reloadData();
+ rs = stmt.executeQuery("SELECT c1, c2
> FROM t1 abcde FOR UPDATE of c1");
+ rs.next();
+ try {
+
> rs.updateString(2,"bbbb");
+ System.out.println("FAIL!!! updateString on
> readonly column should have failed");
+ }
+ catch (SQLException e) {
+
> System.out.println("SQL State : " + e.getSQLState());
+
> System.out.println("Got expected exception " + e.getMessage());
+ }
+
> rs.close();
+ System.out.println("Table t1 has following rows");
+
> dumpRS(stmt.executeQuery("select * from t1"));
+
+
> System.out.println("Positive Test9d - try to updateXXX on a readonly column
> with correlation name. Should get error");
+ reloadData();
+ rs =
> stmt.executeQuery("SELECT c1, c2 as col2 FROM t1 abcde FOR UPDATE of c1");
+
> rs.next();
+ try {
+ rs.updateString(2,"bbbb");
+
> System.out.println("FAIL!!! updateString on readonly column should have
> failed");
+ }
+ catch (SQLException e) {
+ System.out.println("SQL State : "
> + e.getSQLState());
+ System.out.println("Got expected exception " +
> e.getMessage());
+ }
+ rs.close();
+ System.out.println("Table t1 has
> following rows");
+ dumpRS(stmt.executeQuery("select * from t1"));
+
> System.out.println("Positive Test10 - 2 updatable resultsets going against
> the same table, will they conflict?");
conn.setAutoCommit(false);
> reloadData();
@@ -1543,7 +1642,7 @@
> rs.updateRef(ColumnNames[sqlType-1], null);
}
> rs.updateRow();
- if
> (updateXXXRulesTable[sqlType-1][updateXXXName-1].equals("ERROR"))
> {
+ if
> (updateXXXRulesTableForEmbedded[sqlType-1][updateXXXName-1].equals("ERROR"))
> {
System.out.println("FAILURE : We shouldn't reach here. The test should
> have failed earlier on updateXXX or updateRow call");
return;
}
@@ -1553,7
> +1652,7 @@
return;
}
} catch (Throwable e) {
- if
> (updateXXXRulesTable[sqlType-1][updateXXXName-1].equals("ERROR"))
+
> if
> (updateXXXRulesTableForEmbedded[sqlType-1][updateXXXName-1].equals("ERROR"))
> System.out.println(" Got expected exception : " + e.getMessage());
else {
> if ((sqlType == 14 || sqlType == 15 || sqlType == 16) && //we are dealing
> with DATE/TIME/TIMESTAMP column types
@@ -1696,7 +1795,7 @@
continue;
> rs.updateRow();
- if
> (updateXXXRulesTable[sqlType-1][updateXXXName-1].equals("ERROR"))
> {
+ if
> (updateXXXRulesTableForEmbedded[sqlType-1][updateXXXName-1].equals("ERROR"))
> {
System.out.println("FAILURE : We shouldn't reach here. The test should
> have failed earlier on updateXXX or updateRow call");
return;
}
@@ -1706,7
> +1805,7 @@
return;
}
} catch (Throwable e) {
- if
> (updateXXXRulesTable[sqlType-1][updateXXXName-1].equals("ERROR"))
+
> if
> (updateXXXRulesTableForEmbedded[sqlType-1][updateXXXName-1].equals("ERROR"))
> System.out.println(" Got expected exception : " + e.getMessage());
else {
> if ((sqlType == 14 || sqlType == 15 || sqlType == 16) && //we are dealing
> with DATE/TIME/TIMESTAMP column types
@@ -2065,10 +2164,9 @@
stmt =
> conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_UPDATABLE);
rs = stmt.executeQuery("SELECT c1, c2 FROM t1
> FOR UPDATE of c1");
rs.next();
- rs.updateInt(2,22);
try {
-
> rs.updateRow();
- System.out.println("FAIL!!! updateRow should have failed
> because c12 is not the FOR UPDATE columns list.");
+ rs.updateInt(2,22);
+
> System.out.println("FAIL!!! updateInt should have failed because c12 is not
> the FOR UPDATE columns list.");
}
catch (SQLException e) {
> System.out.println("SQL State : " + e.getSQLState());
Index:
> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java
===================================================================
---
> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java
> (revision 167913)
+++
> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java
> (working copy)
@@ -88,7 +88,7 @@
stmt =
> con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
> ResultSet.CONCUR_UPDATABLE);
-
+
// REMIND: might want a usertype case as
> well...
stmt.execute("create table t (i int, s smallint, r real, "+
"d
> double precision, dt date, t time, ts timestamp, "+
@@ -132,7 +132,7 @@
> System.out.println("isReadOnly("+i+"): "+met.isReadOnly(i));
boolean
> writable = met.isWritable(i);
// JCC Supports updatable resultsets so
> isWritable is true
- if ((isDerbyNet && writable == true) ||
+ if
> ((isDerbyNet && writable == true) ||
(!isDerbyNet && writable == false))
> System.out.println("isWritable("+i+"): Expected isWritable value");
> System.out.println("isDefinitelyWritable("+i+"):
> "+met.isDefinitelyWritable(i));
@@ -525,6 +525,7 @@
stmt.close();
> testMutableValues(con);
+
> testCorrelationNamesAndMetaDataCalls(con);
con.close();
> }
@@ -541,6 +542,50 @@
}
+ static private void
> testCorrelationNamesAndMetaDataCalls(Connection conn)
> throws Exception
+ {
+ Statement stmt = conn.createStatement();
+
> stmt.executeUpdate("create table s (a int, b int, c int, d int, e int, f
> int)");
+ stmt.executeUpdate("insert into s values (0,1,2,3,4,5)");
+
> stmt.executeUpdate("insert into s values (10,11,12,13,14,15)");
+
> System.out.println("Run select * from s ss (f, e, d, c, b, a) where f = 0
> and then try getTableName and getSchemaName on columns");
+ ResultSet rs =
> stmt.executeQuery("select * from s ss (f, e, d, c, b, a) where f = 0");
+
> rs.next();
+ ResultSetMetaData met = rs.getMetaData();
+
> System.out.println("getTableName(1): "+met.getTableName(1));
+
> System.out.println("getSchemaName(1): "+met.getSchemaName(1));
+
+
> System.out.println("Run select * from (select * from s) a and then try
> getTableName and getSchemaName on columns");
+ rs =
> stmt.executeQuery("select * from (select * from s) a");
+ rs.next();
+ met =
> rs.getMetaData();
+ System.out.println("getTableName(1):
> "+met.getTableName(1));
+ System.out.println("getSchemaName(1):
> "+met.getSchemaName(1));
+
+ stmt.executeUpdate("create schema s1");
+
> stmt.executeUpdate("create table s1.t1 (c11 int, c12 int)");
+
> stmt.executeUpdate("insert into s1.t1 values (11, 12), (21, 22)");
+
> System.out.println("Run select * from s1.t1 as abc and then try getTableName
> and getSchemaName on columns");
+ rs = stmt.executeQuery("select * from
> s1.t1 as abc");
+ met = rs.getMetaData();
+ System.out.println("Table name
> of first column is " + met.getTableName(1));
+ System.out.println("Schema
> name of first column is " + met.getSchemaName(1));
+
> System.out.println("Table name of second column is " +
> met.getTableName(2));
+ System.out.println("Schema name of second column is
> " + met.getSchemaName(2));
+ System.out.println("Run select abc.c11 from
> s1.t1 as abc and then try getTableName and getSchemaName on columns");
+ rs
> = stmt.executeQuery("select abc.c11 from s1.t1 as abc");
+ met =
> rs.getMetaData();
+ System.out.println("Table name of first column is " +
> met.getTableName(1));
+ System.out.println("Schema name of first column is "
> + met.getSchemaName(1));
+ System.out.println("Run select bcd.a, abc.c11
> from s1.t1 as abc, s as bcd and then try getTableName and getSchemaName on
> columns");
+ rs = stmt.executeQuery("select bcd.a, abc.c11 from s1.t1 as
> abc, s as bcd");
+ met = rs.getMetaData();
+ System.out.println("Table name
> of first column is " + met.getTableName(1));
+ System.out.println("Schema
> name of first column is " + met.getSchemaName(1));
+
> System.out.println("Table name of second column is " +
> met.getTableName(2));
+ System.out.println("Schema name of second column is
> " + met.getSchemaName(2));
+ }
+
static private void doTheTests() throws
> Exception
{
Index:
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out
===================================================================
---
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out
> (revision 167913)
+++
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out
> (working copy)
@@ -47,13 +47,88 @@
Got expected exception This method
> cannot be invoked while the cursor is on the insert row or if the
> concurrency of this ResultSet object is CONCUR_READ_ONLY.
Now attempting to
> send a updateRow on a sql with no FOR UPDATE clause.
SQL State : null
-Got
> expected exception Invalid operation: result set closed
+Got expected
> exception This method cannot be invoked while the cursor is on the insert
> row or if the concurrency of this ResultSet object is CONCUR_READ_ONLY.
> Negative Test6 - request updatable resultset for sql with FOR READ ONLY
> clause
Make sure that we got CONCUR_READ_ONLY? true
+Jira issue Derby-159 :
> Warnings raised by Derby are not getting passed to the Client in Network
> Server Mode
+Will see the warnings in embedded mode only
Now attempting to
> send a delete on a sql with FOR READ ONLY clause.
SQL State : null
Got
> expected exception This method cannot be invoked while the cursor is on the
> insert row or if the concurrency of this ResultSet object is
> CONCUR_READ_ONLY.
Now attempting to send a updateRow on a sql with FOR READ
> ONLY clause.
SQL State : null
Got expected exception This method cannot be
> invoked while the cursor is on the insert row or if the concurrency of this
> ResultSet object is CONCUR_READ_ONLY.
+Negative Test7 - attempt to deleteRow
> & updateRow on updatable resultset when the resultset is not positioned on a
> row
+Make sure that we got CONCUR_UPDATABLE? true
+Now attempt a deleteRow
> without first doing next on the resultset.
+SQL State : XCL08
+Got expected
> exception Cursor 'SQL_CURSH200C7' is not on a row.
+Now attempt a updateRow
> without first doing next on the resultset.
+In embedded mode, updateRow will
> check if it is on a row or not even though no changes have been made to the
> row using updateXXX
+In Network Server mode, if no updateXXX were issued
> before updateRow, then updateRow is a no-op and doesn't check if it is on a
> row or not
+PASS!!! In Network Server mode, this updateRow is a no-op
> because no updateXXX were issued before the updateRow
+ResultSet is
> positioned after the last row. attempt to deleteRow at this point should
> fail!
+SQL State : null
+Got expected exception Invalid operation: result
> set closed
+ResultSet is positioned after the last row. attempt to updateRow
> at this point should fail!
+SQL State : null
+Got expected exception Invalid
> operation: result set closed
+Negative Test8 - attempt deleteRow & updateRow
> on updatable resultset after closing the resultset
+Make sure that we got
> CONCUR_UPDATABLE? true
+SQL State : null
+Got expected exception Invalid
> operation: result set closed
+SQL State : null
+Got expected exception
> Invalid operation: result set closed
+Negative Test9 - try updatable
> resultset on system table
+SQL State : 42Y90
+Got expected exception FOR
> UPDATE is not permitted on this type of statement.
+Negative Test10 - try
> updatable resultset on a view
+SQL State : 42Y90
+Got expected exception FOR
> UPDATE is not permitted on this type of statement.
+Negative Test11 -
> attempt to open updatable resultset when there is join in the select query
> should fail
+SQL State : 42Y90
+Got expected exception FOR UPDATE is not
> permitted on this type of statement.
+Negative Test12 - With autocommit on,
> attempt to drop a table when there is an open updatable resultset on
> it
+Opened an updatable resultset. Now trying to drop that table through
> another Statement
+SQL State : X0X95
+Got expected exception Operation 'DROP
> TABLE' cannot be performed on object 'T1' because there is an open ResultSet
> dependent on that object.
+Since autocommit is on, the drop table exception
> resulted in a runtime rollback causing updatable resultset object to
> close
+SQL State : 42X01
+Got expected exception Syntax error: Encountered
> "(" at line 1, column 19.
+SQL State : 24000
+Got expected exception Invalid
> cursor state - no current row.
+Negative Test13 - foreign key constraint
> failure will cause deleteRow to fail
+SQL State : 23503
+Got expected
> exception DELETE on table 'TABLEWITHPRIMARYKEY' caused a violation of
> foreign key constraint 'FK' for key (1,1). The statement has been rolled
> back.
+Since autocommit is on, the constraint exception resulted in a
> runtime rollback causing updatable resultset object to close
+Jira entry
> Derby-160 : for Network Server because next should have failed
+FAIL!!! next
> should have failed because foreign key constraint failure resulted in a
> runtime rollback
+Negative Test14 - foreign key constraint failure will
> cause updateRow to fail
+SQL State : 42X01
+Got expected exception Syntax
> error: Encountered "(" at line 1, column 36.
+Since autocommit is on, the
> constraint exception resulted in a runtime rollback causing updatable
> resultset object to close
+Jira entry Derby-160 : for Network Server because
> next should have failed
+FAIL!!! next should have failed because foreign key
> constraint failure resulted in a runtime rollback
+Negative Test15 - Can't
> call updateXXX methods on columns that do not correspond to a column in the
> table
+SQL State : null
+Got expected exception Column not
> updatable
+Negative Test16 - Call updateXXX method on out of the range
> column
+There are only 2 columns in the select list and we are trying to
> send updateXXX on column position 3
+SQL State : null
+Got expected
> exception Invalid argument: parameter index 3 is out of range.
+Positive
> Test1a - request updatable resultset for forward only type
> resultset
+requested TYPE_FORWARD_ONLY, CONCUR_UPDATABLE
+got
> TYPE_FORWARD_ONLY? true
+got CONCUR_UPDATABLE? true
+JDBC 2.0 updatable
> resultset apis on this ResultSet object will pass because this is an
> updatable resultset
+column 1 on this row before deleteRow is 1
+column 2 on
> this row before deleteRow is aa
+Since after deleteRow(), in embedded mode,
> ResultSet is positioned before the next row, getXXX will fail
+In Network
> Server mode, the ResultSet stays on the deleted row after deleteRow and
> hence no error for getXXX
+column 1 on this deleted row is 0
+calling
> deleteRow again w/o first positioning the ResultSet on the next row will
> fail
+SQL State : 24000
+Got expected exception Invalid cursor state - no
> current row.
+Position the ResultSet with next()
+Should be able to
> deletRow() on the current row now
Finished testing updateable
> resultsets
Index:
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/resultset.out
===================================================================
---
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/resultset.out
> (revision 167913)
+++
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/resultset.out
> (working copy)
@@ -10,7 +10,7 @@
getColumnLabel(1): I
getColumnName(1): I
> getTableName(1): T
-getSchemaName(1):
+getSchemaName(1): APP
> getCatalogName(1):
getColumnType(1): 4
getPrecision(1): 10
@@ -28,7 +28,7
> @@
getColumnLabel(2): S
getColumnName(2): S
getTableName(2):
> T
-getSchemaName(2):
+getSchemaName(2): APP
getCatalogName(2):
> getColumnType(2): 5
getPrecision(2): 5
@@ -46,7 +46,7 @@
> getColumnLabel(3): R
getColumnName(3): R
getTableName(3):
> T
-getSchemaName(3):
+getSchemaName(3): APP
getCatalogName(3):
> getColumnType(3): 7
getPrecision(3): 7
@@ -64,7 +64,7 @@
> getColumnLabel(4): D
getColumnName(4): D
getTableName(4):
> T
-getSchemaName(4):
+getSchemaName(4): APP
getCatalogName(4):
> getColumnType(4): 8
getPrecision(4): 15
@@ -82,7 +82,7 @@
> getColumnLabel(5): DT
getColumnName(5): DT
getTableName(5):
> T
-getSchemaName(5):
+getSchemaName(5): APP
getCatalogName(5):
> getColumnType(5): 91
getPrecision(5): 10
@@ -100,7 +100,7 @@
> getColumnLabel(6): T
getColumnName(6): T
getTableName(6):
> T
-getSchemaName(6):
+getSchemaName(6): APP
getCatalogName(6):
> getColumnType(6): 92
getPrecision(6): 8
@@ -118,7 +118,7 @@
> getColumnLabel(7): TS
getColumnName(7): TS
getTableName(7):
> T
-getSchemaName(7):
+getSchemaName(7): APP
getCatalogName(7):
> getColumnType(7): 93
getPrecision(7): 26
@@ -136,7 +136,7 @@
> getColumnLabel(8): C
getColumnName(8): C
getTableName(8):
> T
-getSchemaName(8):
+getSchemaName(8): APP
getCatalogName(8):
> getColumnType(8): 1
getPrecision(8): 10
@@ -154,7 +154,7 @@
> getColumnLabel(9): V
getColumnName(9): V
getTableName(9):
> T
-getSchemaName(9):
+getSchemaName(9): APP
getCatalogName(9):
> getColumnType(9): 12
getPrecision(9): 40
@@ -172,7 +172,7 @@
> getColumnLabel(10): DC
getColumnName(10): DC
getTableName(10):
> T
-getSchemaName(10):
+getSchemaName(10): APP
getCatalogName(10):
> getColumnType(10): 3
getPrecision(10): 10
@@ -190,7 +190,7 @@
> getColumnLabel(11): BI
getColumnName(11): BI
getTableName(11):
> T
-getSchemaName(11):
+getSchemaName(11): APP
getCatalogName(11):
> getColumnType(11): -5
getPrecision(11): 19
@@ -208,7 +208,7 @@
> getColumnLabel(12): CBD
getColumnName(12): CBD
getTableName(12):
> T
-getSchemaName(12):
+getSchemaName(12): APP
getCatalogName(12):
> getColumnType(12): -2
getPrecision(12): 10
@@ -226,7 +226,7 @@
> getColumnLabel(13): VBD
getColumnName(13): VBD
getTableName(13):
> T
-getSchemaName(13):
+getSchemaName(13): APP
getCatalogName(13):
> getColumnType(13): -3
getPrecision(13): 10
@@ -244,7 +244,7 @@
> getColumnLabel(14): LVBD
getColumnName(14): LVBD
getTableName(14):
> T
-getSchemaName(14):
+getSchemaName(14): APP
getCatalogName(14):
> getColumnType(14): -4
getPrecision(14): 32700
@@ -262,7 +262,7 @@
> getColumnLabel(15): CL
getColumnName(15): CL
getTableName(15):
> T
-getSchemaName(15):
+getSchemaName(15): APP
getCatalogName(15):
> getColumnType(15): 2005
getPrecision(15): 2147483647
@@ -280,7 +280,7 @@
> getColumnLabel(16): BL
getColumnName(16): BL
getTableName(16):
> T
-getSchemaName(16):
+getSchemaName(16): APP
getCatalogName(16):
> getColumnType(16): 2004
getPrecision(16): 1073741824
@@ -1011,4 +1011,23
> @@
OK EQUALITY OBJECT RETURNED column 5 existing 1
OK EQUALITY OBJECT
> RETURNED column 6 existing 1
COMPLETE testMutableValues
+Run select * from
> s ss (f, e, d, c, b, a) where f = 0 and then try getTableName and
> getSchemaName on columns
+getTableName(1): S
+getSchemaName(1): APP
+Run
> select * from (select * from s) a and then try getTableName and
> getSchemaName on columns
+getTableName(1): S
+getSchemaName(1): APP
+Run
> select * from s1.t1 as abc and then try getTableName and getSchemaName on
> columns
+Table name of first column is T1
+Schema name of first column is
> S1
+Table name of second column is T1
+Schema name of second column is
> S1
+Run select abc.c11 from s1.t1 as abc and then try getTableName and
> getSchemaName on columns
+Table name of first column is T1
+Schema name of
> first column is S1
+Run select bcd.a, abc.c11 from s1.t1 as abc, s as bcd
> and then try getTableName and getSchemaName on columns
+Table name of first
> column is S
+Schema name of first column is APP
+Table name of second column
> is T1
+Schema name of second column is S1
Test resultset finished
Index:
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/updatableResultSet.out
===================================================================
---
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/updatableResultSet.out
> (revision 167913)
+++
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/updatableResultSet.out
> (working copy)
@@ -47,13 +47,88 @@
Got expected exception This method
> cannot be invoked while the cursor is on the insert row or if the
> concurrency of this ResultSet object is CONCUR_READ_ONLY.
Now attempting to
> send a updateRow on a sql with no FOR UPDATE clause.
SQL State : null
-Got
> expected exception Invalid operation: result set closed
+Got expected
> exception This method cannot be invoked while the cursor is on the insert
> row or if the concurrency of this ResultSet object is CONCUR_READ_ONLY.
> Negative Test6 - request updatable resultset for sql with FOR READ ONLY
> clause
Make sure that we got CONCUR_READ_ONLY? true
+Jira issue Derby-159 :
> Warnings raised by Derby are not getting passed to the Client in Network
> Server Mode
+Will see the warnings in embedded mode only
Now attempting to
> send a delete on a sql with FOR READ ONLY clause.
SQL State : null
Got
> expected exception This method cannot be invoked while the cursor is on the
> insert row or if the concurrency of this ResultSet object is
> CONCUR_READ_ONLY.
Now attempting to send a updateRow on a sql with FOR READ
> ONLY clause.
SQL State : null
Got expected exception This method cannot be
> invoked while the cursor is on the insert row or if the concurrency of this
> ResultSet object is CONCUR_READ_ONLY.
+Negative Test7 - attempt to deleteRow
> & updateRow on updatable resultset when the resultset is not positioned on a
> row
+Make sure that we got CONCUR_UPDATABLE? true
+Now attempt a deleteRow
> without first doing next on the resultset.
+SQL State : XCL08
+Got expected
> exception Cursor 'SQL_CURLH000C8' is not on a row.
+Now attempt a updateRow
> without first doing next on the resultset.
+In embedded mode, updateRow will
> check if it is on a row or not even though no changes have been made to the
> row using updateXXX
+In Network Server mode, if no updateXXX were issued
> before updateRow, then updateRow is a no-op and doesn't check if it is on a
> row or not
+PASS!!! In Network Server mode, this updateRow is a no-op
> because no updateXXX were issued before the updateRow
+ResultSet is
> positioned after the last row. attempt to deleteRow at this point should
> fail!
+SQL State : null
+Got expected exception Invalid operation: result
> set closed
+ResultSet is positioned after the last row. attempt to updateRow
> at this point should fail!
+SQL State : null
+Got expected exception Invalid
> operation: result set closed
+Negative Test8 - attempt deleteRow & updateRow
> on updatable resultset after closing the resultset
+Make sure that we got
> CONCUR_UPDATABLE? true
+SQL State : null
+Got expected exception Invalid
> operation: result set closed
+SQL State : null
+Got expected exception
> Invalid operation: result set closed
+Negative Test9 - try updatable
> resultset on system table
+SQL State : 42Y90
+Got expected exception FOR
> UPDATE is not permitted on this type of statement.
+Negative Test10 - try
> updatable resultset on a view
+SQL State : 42Y90
+Got expected exception FOR
> UPDATE is not permitted on this type of statement.
+Negative Test11 -
> attempt to open updatable resultset when there is join in the select query
> should fail
+SQL State : 42Y90
+Got expected exception FOR UPDATE is not
> permitted on this type of statement.
+Negative Test12 - With autocommit on,
> attempt to drop a table when there is an open updatable resultset on
> it
+Opened an updatable resultset. Now trying to drop that table through
> another Statement
+SQL State : X0X95
+Got expected exception Operation 'DROP
> TABLE' cannot be performed on object 'T1' because there is an open ResultSet
> dependent on that object.
+Since autocommit is on, the drop table exception
> resulted in a runtime rollback causing updatable resultset object to
> close
+SQL State : 24000
+Got expected exception Invalid cursor state - no
> current row.
+SQL State : 24000
+Got expected exception Invalid cursor state
> - no current row.
+Negative Test13 - foreign key constraint failure will
> cause deleteRow to fail
+SQL State : 23503
+Got expected exception DELETE on
> table 'TABLEWITHPRIMARYKEY' caused a violation of foreign key constraint
> 'FK' for key (1,1). The statement has been rolled back.
+Since autocommit is
> on, the constraint exception resulted in a runtime rollback causing
> updatable resultset object to close
+Jira entry Derby-160 : for Network
> Server because next should have failed
+FAIL!!! next should have failed
> because foreign key constraint failure resulted in a runtime
> rollback
+Negative Test14 - foreign key constraint failure will cause
> updateRow to fail
+SQL State : 23503
+Got expected exception UPDATE on table
> 'TABLEWITHPRIMARYKEY' caused a violation of foreign key constraint 'FK' for
> key (1,1). The statement has been rolled back.
+Since autocommit is on, the
> constraint exception resulted in a runtime rollback causing updatable
> resultset object to close
+Jira entry Derby-160 : for Network Server because
> next should have failed
+FAIL!!! next should have failed because foreign key
> constraint failure resulted in a runtime rollback
+Negative Test15 - Can't
> call updateXXX methods on columns that do not correspond to a column in the
> table
+SQL State : null
+Got expected exception Column not
> updatable
+Negative Test16 - Call updateXXX method on out of the range
> column
+There are only 2 columns in the select list and we are trying to
> send updateXXX on column position 3
+SQL State : null
+Got expected
> exception Invalid argument: parameter index 3 is out of range.
+Positive
> Test1a - request updatable resultset for forward only type
> resultset
+requested TYPE_FORWARD_ONLY, CONCUR_UPDATABLE
+got
> TYPE_FORWARD_ONLY? true
+got CONCUR_UPDATABLE? true
+JDBC 2.0 updatable
> resultset apis on this ResultSet object will pass because this is an
> updatable resultset
+column 1 on this row before deleteRow is 1
+column 2 on
> this row before deleteRow is aa
+Since after deleteRow(), in embedded mode,
> ResultSet is positioned before the next row, getXXX will fail
+In Network
> Server mode, the ResultSet stays on the deleted row after deleteRow and
> hence no error for getXXX
+column 1 on this deleted row is 0
+calling
> deleteRow again w/o first positioning the ResultSet on the next row will
> fail
+SQL State : 24000
+Got expected exception Invalid cursor state - no
> current row.
+Position the ResultSet with next()
+Should be able to
> deletRow() on the current row now
Finished testing updateable
> resultsets
Index:
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/resultset.out
===================================================================
---
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/resultset.out
> (revision 167913)
+++
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/resultset.out
> (working copy)
@@ -10,7 +10,7 @@
getColumnLabel(1): I
getColumnName(1): I
> getTableName(1): T
-getSchemaName(1):
+getSchemaName(1): APP
> getCatalogName(1):
getColumnType(1): 4
getPrecision(1): 10
@@ -28,7 +28,7
> @@
getColumnLabel(2): S
getColumnName(2): S
getTableName(2):
> T
-getSchemaName(2):
+getSchemaName(2): APP
getCatalogName(2):
> getColumnType(2): 5
getPrecision(2): 5
@@ -46,7 +46,7 @@
> getColumnLabel(3): R
getColumnName(3): R
getTableName(3):
> T
-getSchemaName(3):
+getSchemaName(3): APP
getCatalogName(3):
> getColumnType(3): 7
getPrecision(3): 7
@@ -64,7 +64,7 @@
> getColumnLabel(4): D
getColumnName(4): D
getTableName(4):
> T
-getSchemaName(4):
+getSchemaName(4): APP
getCatalogName(4):
> getColumnType(4): 8
getPrecision(4): 15
@@ -82,7 +82,7 @@
> getColumnLabel(5): DT
getColumnName(5): DT
getTableName(5):
> T
-getSchemaName(5):
+getSchemaName(5): APP
getCatalogName(5):
> getColumnType(5): 91
getPrecision(5): 10
@@ -100,7 +100,7 @@
> getColumnLabel(6): T
getColumnName(6): T
getTableName(6):
> T
-getSchemaName(6):
+getSchemaName(6): APP
getCatalogName(6):
> getColumnType(6): 92
getPrecision(6): 8
@@ -118,7 +118,7 @@
> getColumnLabel(7): TS
getColumnName(7): TS
getTableName(7):
> T
-getSchemaName(7):
+getSchemaName(7): APP
getCatalogName(7):
> getColumnType(7): 93
getPrecision(7): 26
@@ -136,7 +136,7 @@
> getColumnLabel(8): C
getColumnName(8): C
getTableName(8):
> T
-getSchemaName(8):
+getSchemaName(8): APP
getCatalogName(8):
> getColumnType(8): 1
getPrecision(8): 10
@@ -154,7 +154,7 @@
> getColumnLabel(9): V
getColumnName(9): V
getTableName(9):
> T
-getSchemaName(9):
+getSchemaName(9): APP
getCatalogName(9):
> getColumnType(9): 12
getPrecision(9): 40
@@ -172,7 +172,7 @@
> getColumnLabel(10): DC
getColumnName(10): DC
getTableName(10):
> T
-getSchemaName(10):
+getSchemaName(10): APP
getCatalogName(10):
> getColumnType(10): 3
getPrecision(10): 10
@@ -190,7 +190,7 @@
> getColumnLabel(11): BI
getColumnName(11): BI
getTableName(11):
> T
-getSchemaName(11):
+getSchemaName(11): APP
getCatalogName(11):
> getColumnType(11): -5
getPrecision(11): 19
@@ -208,7 +208,7 @@
> getColumnLabel(12): CBD
getColumnName(12): CBD
getTableName(12):
> T
-getSchemaName(12):
+getSchemaName(12): APP
getCatalogName(12):
> getColumnType(12): -2
getPrecision(12): 10
@@ -226,7 +226,7 @@
> getColumnLabel(13): VBD
getColumnName(13): VBD
getTableName(13):
> T
-getSchemaName(13):
+getSchemaName(13): APP
getCatalogName(13):
> getColumnType(13): -3
getPrecision(13): 10
@@ -244,7 +244,7 @@
> getColumnLabel(14): LVBD
getColumnName(14): LVBD
getTableName(14):
> T
-getSchemaName(14):
+getSchemaName(14): APP
getCatalogName(14):
> getColumnType(14): -4
getPrecision(14): 32700
@@ -262,7 +262,7 @@
> getColumnLabel(15): CL
getColumnName(15): CL
getTableName(15):
> T
-getSchemaName(15):
+getSchemaName(15): APP
getCatalogName(15):
> getColumnType(15): 2005
getPrecision(15): 2147483647
@@ -280,7 +280,7 @@
> getColumnLabel(16): BL
getColumnName(16): BL
getTableName(16):
> T
-getSchemaName(16):
+getSchemaName(16): APP
getCatalogName(16):
> getColumnType(16): 2004
getPrecision(16): 1073741824
Index:
> java/testing/org/apache/derbyTesting/functionTests/master/updatableResultSet.out
===================================================================
---
> java/testing/org/apache/derbyTesting/functionTests/master/updatableResultSet.out
> (revision 167913)
+++
> java/testing/org/apache/derbyTesting/functionTests/master/updatableResultSet.out
> (working copy)
@@ -51,6 +51,8 @@
Got expected exception 'updateRow' not
> allowed because the ResultSet is not an updatable ResultSet.
Negative
> Test6 - request updatable resultset for sql with FOR READ ONLY clause
Make
> sure that we got CONCUR_READ_ONLY? true
+Jira issue Derby-159 : Warnings
> raised by Derby are not getting passed to the Client in Network Server
> Mode
+Will see the warnings in embedded mode only
Expected warnings on
> resultset = java.sql.SQLWarning: ResultSet not updatable. Query does not
> qualify to generate an updatable ResultSet.
Now attempting to send a delete
> on a sql with FOR READ ONLY clause.
SQL State : XJ083
@@ -64,6 +66,8 @@
> SQL State : 24000
Got expected exception Invalid cursor state - no current
> row.
Now attempt a updateRow without first doing next on the resultset.
+In
> embedded mode, updateRow will check if it is on a row or not even though no
> changes have been made to the row using updateXXX
+In Network Server mode,
> if no updateXXX were issued before updateRow, then updateRow is a no-op and
> doesn't check if it is on a row or not
SQL State : 24000
Got expected
> exception Invalid cursor state - no current row.
ResultSet is positioned
> after the last row. attempt to deleteRow at this point should fail!
@@
> -122,7 +126,8 @@
JDBC 2.0 updatable resultset apis on this ResultSet object
> will pass because this is an updatable resultset
column 1 on this row
> before deleteRow is 1
column 2 on this row before deleteRow is aa
-Since
> after deleteRow(), ResultSet is positioned before the next row, getXXX will
> fail
+Since after deleteRow(), in embedded mode, ResultSet is positioned
> before the next row, getXXX will fail
+In Network Server mode, the ResultSet
> stays on the deleted row after deleteRow and hence no error for getXXX
SQL
> State : 24000
Got expected exception Invalid cursor state - no current
> row.
calling deleteRow again w/o first positioning the ResultSet on the
> next row will fail
@@ -135,7 +140,8 @@
column 1 on this row after updateInt
> is 234
column 2 on this row before updateString is aa
now updateRow on
> the row
-Since after updateRow(), ResultSet is positioned before the next
> row, getXXX will fail
+Since after updateRow(), in embedded mode, ResultSet
> is positioned before the next row, getXXX will fail
+In Network Server mode,
> the ResultSet stays on the updated row after updateRow and hence no error
> for getXXX
SQL State : 24000
Got expected exception Invalid cursor state -
> no current row.
calling updateRow again w/o first positioning the ResultSet
> on the next row will fail
@@ -269,17 +275,37 @@
Positive Test9c - try to
> updateXXX on a readonly column. Should get error
SQL State : 42X31
Got
> expected exception Column 'C2' is not in FOR UPDATE list of cursor
> 'SQLCUR15'.
+attempt to get an updatable resultset using correlation name
> for an readonly column. It should work
+The sql is SELECT c1, c2 as col2
> FROM t1 abcde FOR UPDATE of c1
Table t1 after updateRow has following rows
> C1,C2
-- --
+ {11,aa }
+ {2,bb }
+ {3,cc }
+Positive Test9c - try to
> updateXXX on a readonly column. Should get error
+SQL State : 42X31
+Got
> expected exception Column 'C2' is not in FOR UPDATE list of cursor
> 'SQLCUR17'.
+Table t1 has following rows
+ C1,C2
+ -- --
{1,aa }
{2,bb }
> {3,cc }
+Positive Test9d - try to updateXXX on a readonly column with
> correlation name. Should get error
+SQL State : 42X31
+Got expected
> exception Column 'COL2' is not in FOR UPDATE list of cursor
> 'SQLCUR18'.
+Table t1 has following rows
+ C1,C2
+ -- --
+ {1,aa }
+ {2,bb
> }
+ {3,cc }
Positive Test10 - 2 updatable resultsets going against the same
> table, will they conflict?
delete using first resultset
attempt to send
> deleteRow on the same row through a different resultset should throw an
> exception
SQL State : XCL08
-Got expected exception Cursor 'SQLCUR17' is
> not on a row.
+Got expected exception Cursor 'SQLCUR20' is not on a row.
> Move to next row in the 2nd resultset and then delete using the second
> resultset
Positive Test11 - setting the fetch size to > 1 will be ignored
> by updatable resultset. Same as updatable cursors
Notice the Fetch Size in
> run time statistics output.
@@ -563,7 +589,9 @@
Got expected exception :
> 'updateBinaryStream' not allowed because the ResultSet is not an updatable
> ResultSet.
Test updateClob on a readonly resultset
Using column position
> as first parameter to updateClob
+ Got expected exception : 'updateClob' not
> allowed because the ResultSet is not an updatable ResultSet.
Using column
> name as first parameter to updateClob
+ Got expected exception :
> 'updateClob' not allowed because the ResultSet is not an updatable
> ResultSet.
Test updateDate on a readonly resultset
Using column position
> as first parameter to updateDate
Got expected exception : 'updateDate' not
> allowed because the ResultSet is not an updatable ResultSet.
@@ -581,7
> +609,9 @@
Got expected exception : 'updateTimestamp' not allowed because
> the ResultSet is not an updatable ResultSet.
Test updateBlob on a readonly
> resultset
Using column position as first parameter to updateBlob
+ Got
> expected exception : 'updateBlob' not allowed because the ResultSet is not
> an updatable ResultSet.
Using column name as first parameter to
> updateBlob
+ Got expected exception : 'updateBlob' not allowed because the
> ResultSet is not an updatable ResultSet.
Test updateBoolean on a readonly
> resultset
Using column position as first parameter to updateBoolean
Got
> expected exception : 'updateBoolean' not allowed because the ResultSet is
> not an updatable ResultSet.
@@ -594,10 +624,14 @@
Got expected exception :
> 'updateNull' not allowed because the ResultSet is not an updatable
> ResultSet.
Test updateArray on a readonly resultset
Using column position
> as first parameter to updateArray
+ Got expected exception : Feature not
> implemented: no details.
Using column name as first parameter to
> updateArray
+ Got expected exception : Feature not implemented: no details.
> Test updateRef on a readonly resultset
Using column position as first
> parameter to updateRef
+ Got expected exception : Feature not implemented:
> no details.
Using column name as first parameter to updateRef
+ Got
> expected exception : Feature not implemented: no details.
Positive Test21 -
> Test all updateXXX(excluding updateObject) methods on all the supported sql
> datatypes
Next datatype to test is SMALLINT
Testing updateShort on SQL
> type SMALLINT
@@ -646,7 +680,9 @@
Got expected exception : An attempt was
> made to get a data value of type 'SMALLINT' from a data value of type
> 'java.io.InputStream'.
Testing updateClob on SQL type SMALLINT
Using
> column position as first parameter to updateClob
+ Got expected exception :
> An attempt was made to get a data value of type 'SMALLINT' from a data value
> of type 'java.sql.Clob'.
Using column name as first parameter to
> updateClob
+ Got expected exception : An attempt was made to get a data
> value of type 'SMALLINT' from a data value of type 'java.sql.Clob'.
Testing
> updateDate on SQL type SMALLINT
Using column position as first parameter to
> updateDate
Got expected exception : An attempt was made to put a data value
> of type 'java.sql.Date' into a data value of type 'SMALLINT'.
@@ -664,7
> +700,9 @@
Got expected exception : An attempt was made to put a data value
> of type 'java.sql.Timestamp' into a data value of type 'SMALLINT'.
Testing
> updateBlob on SQL type SMALLINT
Using column position as first parameter to
> updateBlob
+ Got expected exception : An attempt was made to get a data
> value of type 'SMALLINT' from a data value of type 'java.sql.Blob'.
Using
> column name as first parameter to updateBlob
+ Got expected exception : An
> attempt was made to get a data value of type 'SMALLINT' from a data value of
> type 'java.sql.Blob'.
Testing updateBoolean on SQL type SMALLINT
Using
> column position as first parameter to updateBoolean
Using column name as
> first parameter to updateBoolean
@@ -673,10 +711,14 @@
Using column name as
> first parameter to updateNull
Testing updateArray on SQL type SMALLINT
> Using column position as first parameter to updateArray
+ Got expected
> exception : Feature not implemented: no details.
Using column name as first
> parameter to updateArray
+ Got expected exception : Feature not implemented:
> no details.
Testing updateRef on SQL type SMALLINT
Using column position
> as first parameter to updateRef
+ Got expected exception : Feature not
> implemented: no details.
Using column name as first parameter to
> updateRef
+ Got expected exception : Feature not implemented: no details.
> Next datatype to test is INTEGER
Testing updateShort on SQL type INTEGER
> Using column position as first parameter to updateShort
@@ -724,7 +766,9 @@
> Got expected exception : An attempt was made to get a data value of type
> 'INTEGER' from a data value of type 'java.io.InputStream'.
Testing
> updateClob on SQL type INTEGER
Using column position as first parameter to
> updateClob
+ Got expected exception : An attempt was made to get a data
> value of type 'INTEGER' from a data value of type 'java.sql.Clob'.
Using
> column name as first parameter to updateClob
+ Got expected exception : An
> attempt was made to get a data value of type 'INTEGER' from a data value of
> type 'java.sql.Clob'.
Testing updateDate on SQL type INTEGER
Using column
> position as first parameter to updateDate
Got expected exception : An
> attempt was made to put a data value of type 'java.sql.Date' into a data
> value of type 'INTEGER'.
@@ -742,7 +786,9 @@
Got expected exception : An
> attempt was made to put a data value of type 'java.sql.Timestamp' into a
> data value of type 'INTEGER'.
Testing updateBlob on SQL type INTEGER
Using
> column position as first parameter to updateBlob
+ Got expected exception :
> An attempt was made to get a data value of type 'INTEGER' from a data value
> of type 'java.sql.Blob'.
Using column name as first parameter to
> updateBlob
+ Got expected exception : An attempt was made to get a data
> value of type 'INTEGER' from a data value of type 'java.sql.Blob'.
Testing
> updateBoolean on SQL type INTEGER
Using column position as first parameter
> to updateBoolean
Using column name as first parameter to updateBoolean
@@
> -751,10 +797,14 @@
Using column name as first parameter to updateNull
> Testing updateArray on SQL type INTEGER
Using column position as first
> parameter to updateArray
+ Got expected exception : Feature not implemented:
> no details.
Using column name as first parameter to updateArray
+ Got
> expected exception : Feature not implemented: no details.
Testing updateRef
> on SQL type INTEGER
Using column position as first parameter to updateRef
+
> Got expected exception : Feature not implemented: no details.
Using column
> name as first parameter to updateRef
+ Got expected exception : Feature not
> implemented: no details.
Next datatype to test is BIGINT
Testing
> updateShort on SQL type BIGINT
Using column position as first parameter to
> updateShort
@@ -802,7 +852,9 @@
Got expected exception : An attempt was
> made to get a data value of type 'BIGINT' from a data value of type
> 'java.io.InputStream'.
Testing updateClob on SQL type BIGINT
Using column
> position as first parameter to updateClob
+ Got expected exception : An
> attempt was made to get a data value of type 'BIGINT' from a data value of
> type 'java.sql.Clob'.
Using column name as first parameter to updateClob
+
> Got expected exception : An attempt was made to get a data value of type
> 'BIGINT' from a data value of type 'java.sql.Clob'.
Testing updateDate on
> SQL type BIGINT
Using column position as first parameter to updateDate
Got
> expected exception : An attempt was made to put a data value of type
> 'java.sql.Date' into a data value of type 'BIGINT'.
@@ -820,7 +872,9 @@
Got
> expected exception : An attempt was made to put a data value of type
> 'java.sql.Timestamp' into a data value of type 'BIGINT'.
Testing updateBlob
> on SQL type BIGINT
Using column position as first parameter to updateBlob
+
> Got expected exception : An attempt was made to get a data value of type
> 'BIGINT' from a data value of type 'java.sql.Blob'.
Using column name as
> first parameter to updateBlob
+ Got expected exception : An attempt was made
> to get a data value of type 'BIGINT' from a data value of type
> 'java.sql.Blob'.
Testing updateBoolean on SQL type BIGINT
Using column
> position as first parameter to updateBoolean
Using column name as first
> parameter to updateBoolean
@@ -829,10 +883,14 @@
Using column name as first
> parameter to updateNull
Testing updateArray on SQL type BIGINT
Using
> column position as first parameter to updateArray
+ Got expected exception :
> Feature not implemented: no details.
Using column name as first parameter
> to updateArray
+ Got expected exception : Feature not implemented: no
> details.
Testing updateRef on SQL type BIGINT
Using column position as
> first parameter to updateRef
+ Got expected exception : Feature not
> implemented: no details.
Using column name as first parameter to
> updateRef
+ Got expected exception : Feature not implemented: no details.
> Next datatype to test is DECIMAL(10,5)
Testing updateShort on SQL type
> DECIMAL(10,5)
Using column position as first parameter to updateShort
@@
> -880,7 +938,9 @@
Got expected exception : An attempt was made to get a data
> value of type 'DECIMAL' from a data value of type 'java.io.InputStream'.
> Testing updateClob on SQL type DECIMAL(10,5)
Using column position as first
> parameter to updateClob
+ Got expected exception : An attempt was made to
> get a data value of type 'DECIMAL' from a data value of type
> 'java.sql.Clob'.
Using column name as first parameter to updateClob
+ Got
> expected exception : An attempt was made to get a data value of type
> 'DECIMAL' from a data value of type 'java.sql.Clob'.
Testing updateDate on
> SQL type DECIMAL(10,5)
Using column position as first parameter to
> updateDate
Got expected exception : An attempt was made to put a data value
> of type 'java.sql.Date' into a data value of type 'DECIMAL'.
@@ -898,7
> +958,9 @@
Got expected exception : An attempt was made to put a data value
> of type 'java.sql.Timestamp' into a data value of type 'DECIMAL'.
Testing
> updateBlob on SQL type DECIMAL(10,5)
Using column position as first
> parameter to updateBlob
+ Got expected exception : An attempt was made to
> get a data value of type 'DECIMAL' from a data value of type
> 'java.sql.Blob'.
Using column name as first parameter to updateBlob
+ Got
> expected exception : An attempt was made to get a data value of type
> 'DECIMAL' from a data value of type 'java.sql.Blob'.
Testing updateBoolean
> on SQL type DECIMAL(10,5)
Using column position as first parameter to
> updateBoolean
Using column name as first parameter to updateBoolean
@@
> -907,10 +969,14 @@
Using column name as first parameter to updateNull
> Testing updateArray on SQL type DECIMAL(10,5)
Using column position as
> first parameter to updateArray
+ Got expected exception : Feature not
> implemented: no details.
Using column name as first parameter to
> updateArray
+ Got expected exception : Feature not implemented: no details.
> Testing updateRef on SQL type DECIMAL(10,5)
Using column position as first
> parameter to updateRef
+ Got expected exception : Feature not implemented:
> no details.
Using column name as first parameter to updateRef
+ Got
> expected exception : Feature not implemented: no details.
Next datatype to
> test is REAL
Testing updateShort on SQL type REAL
Using column position as
> first parameter to updateShort
@@ -958,7 +1024,9 @@
Got expected exception
> : An attempt was made to get a data value of type 'REAL' from a data value
> of type 'java.io.InputStream'.
Testing updateClob on SQL type REAL
Using
> column position as first parameter to updateClob
+ Got expected exception :
> An attempt was made to get a data value of type 'REAL' from a data value of
> type 'java.sql.Clob'.
Using column name as first parameter to updateClob
+
> Got expected exception : An attempt was made to get a data value of type
> 'REAL' from a data value of type 'java.sql.Clob'.
Testing updateDate on SQL
> type REAL
Using column position as first parameter to updateDate
Got
> expected exception : An attempt was made to put a data value of type
> 'java.sql.Date' into a data value of type 'REAL'.
@@ -976,7 +1044,9 @@
Got
> expected exception : An attempt was made to put a data value of type
> 'java.sql.Timestamp' into a data value of type 'REAL'.
Testing updateBlob
> on SQL type REAL
Using column position as first parameter to updateBlob
+
> Got expected exception : An attempt was made to get a data value of type
> 'REAL' from a data value of type 'java.sql.Blob'.
Using column name as
> first parameter to updateBlob
+ Got expected exception : An attempt was made
> to get a data value of type 'REAL' from a data value of type
> 'java.sql.Blob'.
Testing updateBoolean on SQL type REAL
Using column
> position as first parameter to updateBoolean
Using column name as first
> parameter to updateBoolean
@@ -985,10 +1055,14 @@
Using column name as
> first parameter to updateNull
Testing updateArray on SQL type REAL
Using
> column position as first parameter to updateArray
+ Got expected exception :
> Feature not implemented: no details.
Using column name as first parameter
> to updateArray
+ Got expected exception : Feature not implemented: no
> details.
Testing updateRef on SQL type REAL
Using column position as first
> parameter to updateRef
+ Got expected exception : Feature not implemented:
> no details.
Using column name as first parameter to updateRef
+ Got
> expected exception : Feature not implemented: no details.
Next datatype to
> test is DOUBLE
Testing updateShort on SQL type DOUBLE
Using column
> position as first parameter to updateShort
@@ -1036,7 +1110,9 @@
Got
> expected exception : An attempt was made to get a data value of type
> 'DOUBLE' from a data value of type 'java.io.InputStream'.
Testing
> updateClob on SQL type DOUBLE
Using column position as first parameter to
> updateClob
+ Got expected exception : An attempt was made to get a data
> value of type 'DOUBLE' from a data value of type 'java.sql.Clob'.
Using
> column name as first parameter to updateClob
+ Got expected exception : An
> attempt was made to get a data value of type 'DOUBLE' from a data value of
> type 'java.sql.Clob'.
Testing updateDate on SQL type DOUBLE
Using column
> position as first parameter to updateDate
Got expected exception : An
> attempt was made to put a data value of type 'java.sql.Date' into a data
> value of type 'DOUBLE'.
@@ -1054,7 +1130,9 @@
Got expected exception : An
> attempt was made to put a data value of type 'java.sql.Timestamp' into a
> data value of type 'DOUBLE'.
Testing updateBlob on SQL type DOUBLE
Using
> column position as first parameter to updateBlob
+ Got expected exception :
> An attempt was made to get a data value of type 'DOUBLE' from a data value
> of type 'java.sql.Blob'.
Using column name as first parameter to
> updateBlob
+ Got expected exception : An attempt was made to get a data
> value of type 'DOUBLE' from a data v
> ...
>
> [Message clipped]
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable
donot return correct values
Posted by Sunitha Kambhampati <ks...@gmail.com>.
David Van Couvering wrote:
> Hi, Sunitha. I don't know if it was encrypted or not. The diff I got
> from stress.multi shows an overload problem:
>
Thanks David for checking.
To know if the stress.multi test was from an encryption run, one way is
to check the derbyall_report.txt . If the test failed as part of
encryption run - you would see something similar to this.
********* Diff file derbyall/encryptionAll/encryption/multi/stress.diff
*** Start: stress jdk1.4.2 encryption:multi 2005-04-21 05:06:15 ***
5a6
> Shutting down due to severe error. Test Failed.
*** End: stress jdk1.4.2 encryption:multi 2005-04-21 05:20:02 ***
You can also check the derbyall_fail.txt.
For e.g. if I see the following in the *fail.txt
derbyall/encryptionAll/encryption.fail:stress/stress.multi --> this
tells me it failed as part of encryption suite
derbyall/derbyall.fail:stress/stress.multi --> this stress.multi test
was the unencrypted run.
Sunitha.
> 7 del
> < ...running last checks via final.sql
> 7 add
> > ...timed out trying to kill all testers,
> > skipping last scripts (if any). NOTE: the
> > likely cause of the problem killing testers is
> > probably not enough VM memory OR test cases that
> > run for very long periods of time (so testers do not
> > have a chance to notice stop() requests
>
> Just for a sanity check, I ran stress.multi on an idle machine (I
> wasn't doing builds or anything else at the time), and this time it
> passed. So I think my machine was just overloaded and the test timed
> out. I don't think it's the same as what you're looking at.
>
> David
>
> Sunitha Kambhampati wrote:
>
>> David Van Couvering wrote:
>>
>>> It built fine and passed all the JDBC api tests, except for
>>> stress.multi, which I think is a problem with my machine and not
>>> your source...
>>
>>
>>
>> Which stress.multi test failed.. was it the encrypted test run ?
>> The reason I ask is I am looking into the encrypted stress.multi
>> failure (Derby241) and wondering if this failure is similar to that
>> one. If you still have the testrun output, can you post some
>> details on it ie - the derby.log , the database etc.
>>
>> Thanks,
>> Sunitha.
>
>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and
ResultSetMetaData.isWritable donot return correct values
Posted by David Van Couvering <Da...@Sun.COM>.
Hi, Sunitha. I don't know if it was encrypted or not. The diff I got
from stress.multi shows an overload problem:
7 del
< ...running last checks via final.sql
7 add
> ...timed out trying to kill all testers,
> skipping last scripts (if any). NOTE: the
> likely cause of the problem killing testers is
> probably not enough VM memory OR test cases that
> run for very long periods of time (so testers do not
> have a chance to notice stop() requests
Just for a sanity check, I ran stress.multi on an idle machine (I wasn't
doing builds or anything else at the time), and this time it passed. So
I think my machine was just overloaded and the test timed out. I don't
think it's the same as what you're looking at.
David
Sunitha Kambhampati wrote:
> David Van Couvering wrote:
>
>> It built fine and passed all the JDBC api tests, except for
>> stress.multi, which I think is a problem with my machine and not your
>> source...
>
>
> Which stress.multi test failed.. was it the encrypted test run ? The
> reason I ask is I am looking into the encrypted stress.multi failure
> (Derby241) and wondering if this failure is similar to that one. If
> you still have the testrun output, can you post some details on it
> ie - the derby.log , the database etc.
>
> Thanks,
> Sunitha.
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable
donot return correct values
Posted by Sunitha Kambhampati <ks...@gmail.com>.
David Van Couvering wrote:
> It built fine and passed all the JDBC api tests, except for
> stress.multi, which I think is a problem with my machine and not your
> source...
Which stress.multi test failed.. was it the encrypted test run ? The
reason I ask is I am looking into the encrypted stress.multi failure
(Derby241) and wondering if this failure is similar to that one. If
you still have the testrun output, can you post some details on it
ie - the derby.log , the database etc.
Thanks,
Sunitha.
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and
ResultSetMetaData.isWritable donot return correct values
Posted by David Van Couvering <Da...@Sun.COM>.
Hi, Mamta, looks good (from my fairly shallow knowledge of the code).
It built fine and passed all the JDBC api tests, except for
stress.multi, which I think is a problem with my machine and not your
source... I was trying to do a lot of other things at the same time and
I think it just timed out.
David
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable
donot return correct values
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Satheesh Bandaram wrote:
> I am getting ready to submit this patch.
>
> Satheesh
>
> Mamta Satoor wrote:
>
>>Hi David,
>>
>>I have attached a new patch to take care of the comments from your review.
>>2)The change in ResultColumnDescriptor.java for getSourceSchemaName is
>>for clarity and consistency reasons (similar to getSourceTableName).
>>With this
>>change, EmbedResultSetMetaData now calls getSourceXXXName for
>>getTableName and getSchemaName. Similarly, in
>>GenericColumnDescriptor(which implements ResultColumnDescriptor), we
>>have getSourceXXXName to keep the source table and source schema name.
I'm still confused by the various get methods for table name and schema
names. Additional comments on getSourceTableName() explictly stating
that it does get the name of the underlying table would be useful. Then
its description matches the behaviour implied by its method name.
Then with this patch ColumnReference has a getSchemaName() and a
getSourceSchemaName(). I'm unclear on what the intended behaviour of
each is, and why we need two methods. If getTableName() means return the
"user" name or correlation name, then logically getSchemaName() would
follow the same pattern, but user names or correlation names don't have
schemas.
This isn't helped by the fact that the comments for the ValueNode
methods getTableName and getSchemaName do not have clear or correct
comments, and that's the place where logically their behaviour is defined.
Maybe this patch is ok without addressing these issues, but I'm worried
that it might be making a confused area even more confused.
Dan.
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Posted by Mamta Satoor <ms...@gmail.com>.
Hi David,
I have attached a new patch to take care of the comments from your review.
1)Good catch about
impl.sql.compile.ResultColumnList.getResultColumnThroughExpression().
It is left over code from another solution I was trying to fix the
problem. I have taken it out of the review package attached to this
mail.
2)The change in ResultColumnDescriptor.java for getSourceSchemaName is
for clarity and consistency reasons (similar to getSourceTableName).
With this
change, EmbedResultSetMetaData now calls getSourceXXXName for
getTableName and getSchemaName. Similarly, in
GenericColumnDescriptor(which implements ResultColumnDescriptor), we
have getSourceXXXName to keep the source table and source schema name.
3)I have reformatted code and comments to not exceed 80 characters.
Also, changed the comments for method commonCodeForUpdateableBySql
from .. to /** and */
thanks,
Mamta
On 5/2/05, David Van Couvering <Da...@sun.com> wrote:
> Hi, Mamta, this looks good. It built, and I ran as many tests as I
> could before I had to leave for the day. My God, those tests take a
> long time to run. But that's a topic for a separate discussion :)
>
> Here are my comments and questions...
>
> - What you have looks good and makes sense, but I don't know the code
> well enough to know if you're missing something. I guess the tests help
> guarantee that, but someone more familiar with the code taking a look
> would be great.
>
> - I was curious how
> impl.sql.compile.ResultColumnList.getResultColumnThroughExpression() was
> used. In NetBeans I searched for all usages of it and could find none.
> To double-check, I did a full search of the codeline and only found
> it where it is defined, and no uses. Is there a reason to have this
> method if nothing uses it?
>
> - in ResultColumnDescriptor.java, why did you change the method from
> getSchemaName() to getSourceSchemaName()? Is this just to make it more
> clear what the method is doing?
>
> - A lot of your comments and code seem to far exceed 80 characters in
> length per line. This makes it hard to read in diff output and
> text-based editors, and it requires scrolling in IDEs. Could you please
> limit your source lines to 80 characters?
>
> - The method commonCodeForUpdateableBySql in ResultColumnList.java
> should have comments with /** and */ rather than // It took me a while
> in 'vi' to determine this was a new method, to the eye it looks like a
> continuation of the previous method.
>
> David
>
> Mamta Satoor wrote:
>
> > Hi,
> >
> > I am sorry if I sound like a broken record, but please, will someone
> > review this? And if no concerns from anyone, will a commiter commit
> > it?
> >
> > thanks,
> > Mamta
> >
> > On 4/27/05, Mamta Satoor <ms...@gmail.com> wrote:
> >
> >>Hi,
> >>
> >>I wondered if anyone got a chance to review this patch?
> >>
> >>thanks,
> >>Mamta
> >>
> >>On 4/24/05, Mamta Satoor <ms...@gmail.com> wrote:
> >>
> >>>Hi Dan,
> >>>
> >>>I have a new patch for this bug which also fixes the problem you
> >>>brought up with sql select * from a.t as X. The fix for this required
> >>>change in impl.sql.compile.FromBaseTable's method genResultColList().
> >>>I changed the code such that we set the TableDescriptor on the
> >>>ColumnDescriptor instance. This TableDescriptor is later used by
> >>>ResultColumn.getTableName to get the base table name of the column. In
> >>>addition to that, I changed ColumnReference.getSourceTableName and
> >>>ColumnReference.getSourceSchemaName so that they don't look at the
> >>>user supplied correlation name (if any) to fetch the base table/schema
> >>>name.
> >>>
> >>>I have also added some test cases for the code changes above in
> >>>jdbcapi/resultset.java
> >>>
> >>>Other than this, the rest of the patch stays the same as what you
> >>>tried applying last week.
> >>>
> >>>I have run the tests and there is no new failure because of my changes.
> >>>
> >>>svn stat output
> >>>M java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\CursorNode.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\ValueNode.java
> >>>M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
> >>>M java\engine\org\apache\derby\impl\sql\GenericColumnDescriptor.java
> >>>M java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
> >>>M java\engine\org\apache\derby\impl\jdbc\EmbedResultSetMetaData.java
> >>>M java\engine\org\apache\derby\iapi\sql\dictionary\ColumnDescriptor.java
> >>>M java\engine\org\apache\derby\iapi\sql\ResultColumnDescriptor.java
> >>>M java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
> >>>M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultset.java
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\resultset.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\updatableResultSet.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\resultset.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
> >>>M java\testing\org\apache\derbyTesting\functionTests\master\resultset.out
> >>>
> >>>Please commit the patch if there are no further issues,
> >>>Mamta
> >>>
> >>>On 4/22/05, Mamta Satoor <ms...@gmail.com> wrote:
> >>>
> >>>>Hi Dan,
> >>>>
> >>>>I did some research into this. You are right that for the sql
> >>>>select * from a.t as X
> >>>>the existing code will return ABC using both getTableName and
> >>>>getSourceTableName. Looking at the history of ColumnReference before
> >>>>the code was
> >>>>contributed, the getSourceTableName was added to Cloudscape so that
> >>>>ResultSetMetaData.getTableName will return the correct value which is
> >>>>base table
> >>>>name. Seems like over the time, this functionality got broken again.
> >>>>
> >>>>In my code line, I tried changing ColumnReference.getSourceTableName
> >>>>to following
> >>>>public String getSourceTableName()
> >>>>{
> >>>>return ((source != null) ? source.getTableName() : null);
> >>>>}
> >>>>
> >>>>But, that did not solve the problem. The source.getTableName() invokes
> >>>>ResultColumn.getTableName which is currently coded as follows
> >>>>public String getTableName()
> >>>>{
> >>>> if (tableName != null)
> >>>> {
> >>>> return tableName;
> >>>> }
> >>>> if ((columnDescriptor!=null) &&
> >>>> (columnDescriptor.getTableDescriptor() != null))
> >>>> {
> >>>> return columnDescriptor.getTableDescriptor().getName();
> >>>> }
> >>>> else
> >>>> {
> >>>> return expression.getTableName();
> >>>> }
> >>>>}
> >>>>
> >>>>In the code above, the first 2 if conditions return false and hence
> >>>>expression.getTableName() get called which returns ABC for the sql
> >>>>above. And this
> >>>>is the problem in my opinion. The 2nd if condition needs to succeed in
> >>>>order to get the correct value for table name(currently, the 2nd if
> >>>>condition
> >>>>returns false because columnDescriptor.getTableDescriptor() returns
> >>>>null). columnDescriptor has its table descriptor set to null since it
> >>>>got
> >>>>instantiated via SYSCOLUMNSRowFactory which passes the uuid for the
> >>>>table but not the table descriptor. I tried changing
> >>>>ColumnDescriptor's
> >>>>2nd constructor(the one which doesn't get table descriptor passed to
> >>>>it) to try to get the table descriptor from the uuid by calling
> >>>>getDataDictionary.getTableDescriptor(uuid), but it gives me Raw Store
> >>>>internal error. I will continue to research but does someone looking
> >>>>at this
> >>>>explanation have any thoughts on the program flow or issue in general?
> >>>>
> >>>>thanks,
> >>>>Mamta
> >>>>
> >>>>
> >>>>On 4/20/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> >>>>
> >>>>>The patch applies fine and passes the tests but I need some
> >>>>>clarification on some methods in ColumnReference.
> >>>>>
> >>>>>ColumnReference has these class specific methods
> >>>>>
> >>>>>getSourceTableName()
> >>>>>getSourceSchemaName() [added by this contribution]
> >>>>>
> >>>>>and because it is a ValueNode it also has
> >>>>>
> >>>>>getTableName
> >>>>>getSchemaName
> >>>>>
> >>>>>Mamta, can you clarify the difference between the getSource*Name methods
> >>>>>and get*Name methods? Eventually as comments in the javadoc for these
> >>>>>methods, but some discussion on the list may be useful.
> >>>>>
> >>>>>I'm worried because most of the bugs around correlation names I think
> >>>>>were due to having multiple methods with similar and maybe misleading
> >>>>>names but no clear definition of what they returned.
> >>>>>
> >>>>>In this specific case, my gut reaction from the names of the
> >>>>>getSource*Name methods is that they return the actual name of the
> >>>>>underlying table the column comes from. But looking the implementation &
> >>>>>comments of getTableName and getSourceTableName in ColumnReference.java
> >>>>>it seems in this case
> >>>>>
> >>>>>select * from a.t as X
> >>>>>
> >>>>>that both methods will return X.
> >>>>>
> >>>>>Dan.
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
>
>
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and
ResultSetMetaData.isWritable donot return correct values
Posted by David Van Couvering <Da...@Sun.COM>.
Hi, Mamta, this looks good. It built, and I ran as many tests as I
could before I had to leave for the day. My God, those tests take a
long time to run. But that's a topic for a separate discussion :)
Here are my comments and questions...
- What you have looks good and makes sense, but I don't know the code
well enough to know if you're missing something. I guess the tests help
guarantee that, but someone more familiar with the code taking a look
would be great.
- I was curious how
impl.sql.compile.ResultColumnList.getResultColumnThroughExpression() was
used. In NetBeans I searched for all usages of it and could find none.
To double-check, I did a full search of the codeline and only found
it where it is defined, and no uses. Is there a reason to have this
method if nothing uses it?
- in ResultColumnDescriptor.java, why did you change the method from
getSchemaName() to getSourceSchemaName()? Is this just to make it more
clear what the method is doing?
- A lot of your comments and code seem to far exceed 80 characters in
length per line. This makes it hard to read in diff output and
text-based editors, and it requires scrolling in IDEs. Could you please
limit your source lines to 80 characters?
- The method commonCodeForUpdateableBySql in ResultColumnList.java
should have comments with /** and */ rather than // It took me a while
in 'vi' to determine this was a new method, to the eye it looks like a
continuation of the previous method.
David
Mamta Satoor wrote:
> Hi,
>
> I am sorry if I sound like a broken record, but please, will someone
> review this? And if no concerns from anyone, will a commiter commit
> it?
>
> thanks,
> Mamta
>
> On 4/27/05, Mamta Satoor <ms...@gmail.com> wrote:
>
>>Hi,
>>
>>I wondered if anyone got a chance to review this patch?
>>
>>thanks,
>>Mamta
>>
>>On 4/24/05, Mamta Satoor <ms...@gmail.com> wrote:
>>
>>>Hi Dan,
>>>
>>>I have a new patch for this bug which also fixes the problem you
>>>brought up with sql select * from a.t as X. The fix for this required
>>>change in impl.sql.compile.FromBaseTable's method genResultColList().
>>>I changed the code such that we set the TableDescriptor on the
>>>ColumnDescriptor instance. This TableDescriptor is later used by
>>>ResultColumn.getTableName to get the base table name of the column. In
>>>addition to that, I changed ColumnReference.getSourceTableName and
>>>ColumnReference.getSourceSchemaName so that they don't look at the
>>>user supplied correlation name (if any) to fetch the base table/schema
>>>name.
>>>
>>>I have also added some test cases for the code changes above in
>>>jdbcapi/resultset.java
>>>
>>>Other than this, the rest of the patch stays the same as what you
>>>tried applying last week.
>>>
>>>I have run the tests and there is no new failure because of my changes.
>>>
>>>svn stat output
>>>M java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java
>>>M java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java
>>>M java\engine\org\apache\derby\impl\sql\compile\CursorNode.java
>>>M java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
>>>M java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java
>>>M java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
>>>M java\engine\org\apache\derby\impl\sql\compile\ValueNode.java
>>>M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
>>>M java\engine\org\apache\derby\impl\sql\GenericColumnDescriptor.java
>>>M java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
>>>M java\engine\org\apache\derby\impl\jdbc\EmbedResultSetMetaData.java
>>>M java\engine\org\apache\derby\iapi\sql\dictionary\ColumnDescriptor.java
>>>M java\engine\org\apache\derby\iapi\sql\ResultColumnDescriptor.java
>>>M java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
>>>M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultset.java
>>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\resultset.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\updatableResultSet.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\resultset.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
>>>M java\testing\org\apache\derbyTesting\functionTests\master\resultset.out
>>>
>>>Please commit the patch if there are no further issues,
>>>Mamta
>>>
>>>On 4/22/05, Mamta Satoor <ms...@gmail.com> wrote:
>>>
>>>>Hi Dan,
>>>>
>>>>I did some research into this. You are right that for the sql
>>>>select * from a.t as X
>>>>the existing code will return ABC using both getTableName and
>>>>getSourceTableName. Looking at the history of ColumnReference before
>>>>the code was
>>>>contributed, the getSourceTableName was added to Cloudscape so that
>>>>ResultSetMetaData.getTableName will return the correct value which is
>>>>base table
>>>>name. Seems like over the time, this functionality got broken again.
>>>>
>>>>In my code line, I tried changing ColumnReference.getSourceTableName
>>>>to following
>>>>public String getSourceTableName()
>>>>{
>>>>return ((source != null) ? source.getTableName() : null);
>>>>}
>>>>
>>>>But, that did not solve the problem. The source.getTableName() invokes
>>>>ResultColumn.getTableName which is currently coded as follows
>>>>public String getTableName()
>>>>{
>>>> if (tableName != null)
>>>> {
>>>> return tableName;
>>>> }
>>>> if ((columnDescriptor!=null) &&
>>>> (columnDescriptor.getTableDescriptor() != null))
>>>> {
>>>> return columnDescriptor.getTableDescriptor().getName();
>>>> }
>>>> else
>>>> {
>>>> return expression.getTableName();
>>>> }
>>>>}
>>>>
>>>>In the code above, the first 2 if conditions return false and hence
>>>>expression.getTableName() get called which returns ABC for the sql
>>>>above. And this
>>>>is the problem in my opinion. The 2nd if condition needs to succeed in
>>>>order to get the correct value for table name(currently, the 2nd if
>>>>condition
>>>>returns false because columnDescriptor.getTableDescriptor() returns
>>>>null). columnDescriptor has its table descriptor set to null since it
>>>>got
>>>>instantiated via SYSCOLUMNSRowFactory which passes the uuid for the
>>>>table but not the table descriptor. I tried changing
>>>>ColumnDescriptor's
>>>>2nd constructor(the one which doesn't get table descriptor passed to
>>>>it) to try to get the table descriptor from the uuid by calling
>>>>getDataDictionary.getTableDescriptor(uuid), but it gives me Raw Store
>>>>internal error. I will continue to research but does someone looking
>>>>at this
>>>>explanation have any thoughts on the program flow or issue in general?
>>>>
>>>>thanks,
>>>>Mamta
>>>>
>>>>
>>>>On 4/20/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>>>>
>>>>>The patch applies fine and passes the tests but I need some
>>>>>clarification on some methods in ColumnReference.
>>>>>
>>>>>ColumnReference has these class specific methods
>>>>>
>>>>>getSourceTableName()
>>>>>getSourceSchemaName() [added by this contribution]
>>>>>
>>>>>and because it is a ValueNode it also has
>>>>>
>>>>>getTableName
>>>>>getSchemaName
>>>>>
>>>>>Mamta, can you clarify the difference between the getSource*Name methods
>>>>>and get*Name methods? Eventually as comments in the javadoc for these
>>>>>methods, but some discussion on the list may be useful.
>>>>>
>>>>>I'm worried because most of the bugs around correlation names I think
>>>>>were due to having multiple methods with similar and maybe misleading
>>>>>names but no clear definition of what they returned.
>>>>>
>>>>>In this specific case, my gut reaction from the names of the
>>>>>getSource*Name methods is that they return the actual name of the
>>>>>underlying table the column comes from. But looking the implementation &
>>>>>comments of getTableName and getSourceTableName in ColumnReference.java
>>>>>it seems in this case
>>>>>
>>>>>select * from a.t as X
>>>>>
>>>>>that both methods will return X.
>>>>>
>>>>>Dan.
>>>>>
>>>>>
>>>>
>>>
>>>
>>