db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-924) new JDBC4 metadata API getFunctions() needs to be implemented
Date Wed, 12 Apr 2006 08:43:54 GMT
Dyre.Tjeldvoll@Sun.COM writes:

> "Knut Anders Hatlen (JIRA)" <derby-dev@db.apache.org> writes:
>> Knut Anders Hatlen commented on DERBY-924:
>> ------------------------------------------
>> Committed revision 393304.
>> I made some small changes to the patch before committing it:
>>    - two of the jdk16 canons touched by the patch were removed by the
>>      DERBY-1178 fix
>>    - updated jdk13 canon for metadata.java on DerbyNetClient
> This I don't understand. Where is this master? I ran
> find java/testing -name 'metadata.out' but all I got was
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk16/metadata.out
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/metadata.out
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/metadata.out
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk14/metadata.out
> java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/metadata.out
> java/testing/org/apache/derbyTesting/functionTests/master/metadata.out
> I see DerbyNetClient/jdk14 and DerbyNetClient/jdk16, but no
> DerbyNetClient/jdk13 ?

DerbyNetClient/metadata.out is for jdk<=1.3
DerbyNetClient/jdk14/metadata.out is for jdk14 and jdk15
DerbyNetClient/jdk16/metadata.out is for jdk>=1.6

>> I still have one minor question about the patch. getFunctionsX() ends
>> with these two lines:
>>         lastGetProceduresResultSet_ = executeCatalogQuery(cs);
>>         return lastGetProceduresResultSet_;
>> Should this have been lastGetFunctionsResultSet_ instead? Not that it
>> matters, since none of the lastGetXXXResultSet_ variables seem to have
>> any other purpose than ensuring that a lot of garbage is kept on the
>> heap.
> "When in Rome, do as the Romans do". That's how the getProceduresX()
> method does it. And since this is just a ResultSet reference that
> isn't needed after the method returns, I didn't see the point in
> increasing the footprint by adding another variable with a different
> name. Maybe I should have given the variable a more generic name when
> I reused it, but on the other hand, that would have yielded a larger
> diff...

Do you understand why the lastGetXXXResultSet_ variables are there in
the first place? There are 15 of them, but none of them is ever
accessed. I have removed them in my sandbox and started a derbyall. If
it doesn't break anything, I think I will file a JIRA to get rid of

Knut Anders

View raw message