Re: JDK 1.4 challenge, opinions please

On Sun, 2001-12-16 at 14:43, Rene Pijlman wrote:
> Now the problem: there are many methods in DatabaseMetaData.java
> that create a ResultSet. However, the common implementation in
> jdbcge2/DatabaseMetaData cannot create a ResultSet, since the
> type of the ResultSet is unknown (it's an
> org.postgresql.jdbc2.ResultSet or an
> org.postgresql.jdbc3.ResultSet, depending on the compilation
> environment).

Couldn't the method that creates the resultSet to be used/abused be an
abstract method that the jdbcge2/DatabaseMetaData calls?  For instance,
jdbcge2/DatabaseMetaData has a protected method
   protected  ResultSet getResultSet();
and then the jdbc2/DatabaseMetaData and jdbc3/DatabaseMetaData classes
that inherit from jdbcge2/DatabaseMetaData implement it to return the
proper one?  Then jdbcge2/DatabaseMetaData can set the needed data in
the ResultSet.  You could also then have an empty method in
jdbcge2/DatabaseMetaData that can be overriden so the subclasses can
make more changes when the initial jdbcge2 stuff is done. (Kinda like
adding in a hook)

Did that make sense? ;-)



> A simple solution would be to move such methods from jdbcge2 to
> jdbc2 and jdbc3, but this would create an awfull lot of code
> duplication.
>
> So I'm inclined to refactor the code and create wrapper methods
> in jdbc2 and jdbc3 that call common code in helper methods in
> jdbcge2.
>
> This applies to the following methods in DatabaseMetaData:
> - getProcedures
> - getProcedureColumns
> - getTables
> - getSchemas
> - getTableTypes
> - getColumns
> - getColumnPrivileges
> - getTablePrivileges
> - getBestRowIdentifier
> - getImportedExportedKeys
> - getTypeInfo
> - getIndexInfo
>
> Do we agree that this refactoring - touching lots of code - is
> desirable?
>
> This idea may apply to jdbc1 as well, which would allow us to
> reduce the amount of code duplication that currently exists
> between jdbc1 and jdbc2.
>
> There are other problems up ahead though, such as common code in
> jdbcge2 that references constants from java.sql (e.g.
> FETCH_FORWARD). I'm not sure yet if we can resolve that easily
> without code duplication.
>
> An alternative approach we should consider is some sort of
> preprocessing in the build process (#ifdef JDBC3). But that's
> generally considered un-javaish and it would inconvenience
> building and debugging the driver with standard IDE's.
>
> Regards,
> René Pijlman <rene@lab.applinet.nl>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--

Virtually,
Ned Wolpert <ned.wolpert@knowledgenet.com>

D08C2F45:  28E7 56CB 58AC C622 5A51  3C42 8B2B 2739 D08C 2F45