Re: (forw) [bfl@florianbruckner.com: AW: Reversedb tool and
От | Dave Cramer |
---|---|
Тема | Re: (forw) [bfl@florianbruckner.com: AW: Reversedb tool and |
Дата | |
Msg-id | 1040214533.14876.312.camel@inspiron.cramers обсуждение исходный текст |
Список | pgsql-jdbc |
Anders, 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? 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 <davec@fastcrypt.com> Cramer Consulting -- Dave Cramer <Dave@micro-automation.net>
В списке pgsql-jdbc по дате отправления: