Thread: (forw) [bfl@florianbruckner.com: AW: Reversedb tool and getPrimaryKeys]

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 -----

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@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
--
Dave Cramer <Dave@micro-automation.net>

* Dave Cramer (davec@fastcrypt.com) wrote:
> I applied the patch locally, and tried out the reversedb tool, it
> consumes alot of processor, and I didn't wait for it to return. Does it
> work?

It took a lot of processor here too on a relatively small database. But it
did work for me with the patch applied :) XML was generated as expected.


Anders

--
Anders Hermansen
YoYo Mobile as