Re: (forw) [bfl@florianbruckner.com: AW: Reversedb tool and

Any chance of you extending one of the test cases for this to add a
test? I am leaning towards applying it.

Dave
On Wed, 2002-12-18 at 03:57, Anders Hermansen wrote:
> 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(at)florianbruckner(dot)com> -----
>
> Date: Tue, 17 Dec 2002 20:01:43 +0100
> To: "OJB Developers List" <ojb-dev(at)jakarta(dot)apache(dot)org>
> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
> Reply-To: "OJB Developers List" <ojb-dev(at)jakarta(dot)apache(dot)org>
> From: "Florian Bruckner" <bfl(at)florianbruckner(dot)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
--
Dave Cramer <Dave(at)micro-automation(dot)net>