Reading the forwarded message and the patch I sent earlier. Does this
modification really hurt anyone? I can't see it do anything but good
things.
Dave? Anybody?
Anders
--
Anders Hermansen
YoYo Mobile as
----- Forwarded message from Florian Bruckner <bfl@florianbruckner.com> -----
Date: Tue, 17 Dec 2002 20:01:43 +0100
To: "OJB Developers List" <ojb-dev@jakarta.apache.org>
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Reply-To: "OJB Developers List" <ojb-dev@jakarta.apache.org>
From: "Florian Bruckner" <bfl@florianbruckner.com>
Subject: AW: Reversedb tool and getPrimaryKeys
Hi Anders,
> org/apache/ojb/tools/mapping/reversedb/DbMeta.java line 279:
> rs = this.dbMeta.getPrimaryKeys(null, null, null);
>
> The javadoc for the DatabaseMetaData.getPrimaryKeys method says this:
> <quote>
> Parameters:
> catalog - a catalog name; must match the catalog name as it
> is stored in the database; "" retrieves those without a catalog;
> null means that the catalog name should not be used to narrow the search
> schema - a schema name; must match the schema name as it is
> stored in the database; "" retrieves those without a schema; null
> means that the schema name should not be used to narrow the search
> table - a table name; must match the table name as it is
> stored in the database
> </quote>
>
> As you can see catalog and schema is specified to have null as a valid
> value, but table is not.
>
> I made a patch agains postgresql jdbc driver to make it work as the
> reversedb application expected, but it was rejected by the psotgresql
> jdbc developers because it is not according to the jdbc specifications.
>
> Is this a bug in the reversedb application?
> If it is I can probably prepare a patch which will use getPrimaryKeys
> for each table.
I'd say not quite a bug because it works on some DBMS, e.g. Oracle and
Informix. The modification itself is rather simple, early versions of
reversedb resolved primary keys this way. Problem is, this hits performance
severely. On Oracle it already takes a few minutes to read the metadata and
AFAIR this modification would double the time needed for reverse
engineering. So lets call it a suboptimal optimization ;-).
Any ideas how we could be more JDBC-compliant while maintaining performance
are appreciated.
best regards,
Florian
--
To unsubscribe, e-mail: <mailto:ojb-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ojb-dev-help@jakarta.apache.org>
----- End forwarded message -----