db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: [jira] Commented: (DERBY-924) new JDBC4 metadata API getFunctions() needs to be implemented
Date Wed, 12 Apr 2006 08:04:30 GMT
"Knut Anders Hatlen (JIRA)" <derby-dev@db.apache.org> writes:

>     [ http://issues.apache.org/jira/browse/DERBY-924?page=comments#action_12374100 ]

> 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

I see DerbyNetClient/jdk14 and DerbyNetClient/jdk16, but no
DerbyNetClient/jdk13 ?

> 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


View raw message