blank catalog makes Table.qualify() fail

jeffwalker · **Joined:** Mon Feb 02, 2009 2:49 pm **Posts:** 15

So, I'm hoping for a RTFM fail, but:

The database is Derby 10.5.3.
Hibernate 3.3.2.GA, HibernateTools-3.2.4.GA-R200905070146-H18.zip\plugins\org.hibernate.eclipse_3.2.4.GA-R200905070146-H18\lib\tools\hibernate-tools.jar

I am using ant to reverse engineer a small database
In my reverse engineering strategy, I have a SchemaSelection like:

Code:

new SchemaSelection(null, "SELBD","BOARD")

When the table is put into the MappingsDatabaseCollector, they go in the map with keys like:

Code:

SELBD.BOARD

but by the time we get to JDBCReader.resolveForeignKeys(), it has replaced the null catalog with blank, thus Table.qualify() yeilds

Code:

.SELBD.BOARD

thus, the lookup for the foreign key fails, and I get no association collections in the pojos.

I have tried null, "", ".*" for the catalog spec in the strategy, and also the same in the reveng.xml file.

Thanks.

edit: I've looked at JDBCMetaDataDialect (since Derby doesn't seem to have a dialect class) and Derby is returning "" (that is, a zero length string) for the catalog. I looked at the OracleMetaDataDialect for reference and it returns null.
Is this really what is at fault?
edit2:looks like it will be JDBCMetaDataDialect.getExportedKeys() is failing me. I'll find out for sure tomorrow.

So, known issue with Derby? no one uses Derby?

jeffwalker · **Joined:** Mon Feb 02, 2009 2:49 pm **Posts:** 15

Yes, so that worked. I have 2 methods in my derby MetaDataDialect

Code:

protected void putTablePart(Map element, ResultSet tableRs) throws SQLException {
   super.putTablePart(element, tableRs);
   element.put("TABLE_CAT", null);
}

Which turns out to be not needed because the catalog (and schema) are set to null if they are blank (trimmed string length = 0)

and

Code:

protected void putExportedKeysPart(Map element, ResultSet rs) throws SQLException {
   super.putExportedKeysPart(element, rs);
   element.put( "PKTABLE_CAT", null); // instead of "", which derby returns.
   element.put( "FKTABLE_CAT", null);
}

Which actually fixed it. I think an actual production version should check if it is blank and set it to null then; just in case derby started supporting catalogs.

But, I think the null/blank thing should be handled elsewhere, like line 197 in processForeignKeys() of JDBCReader.java. This would be congruent to how processTables() works.

Shall I put this in jira? or is this a known problem that I didn't find?

Incidentally, I found another interesting thing: in my reverse engineering strategy class, I needed to do this:

Code:

public void configure(ReverseEngineeringRuntimeInfo runtimeInfo) {
   super.configure(runtimeInfo);
   this.runtimeInfo = runtimeInfo;
}

Otherwise, a null-pointer-exception is thrown when getting the runtime info via the parent (default reverse engineering strategy). This is not a big deal, the only reason I found this strange is that its friend, setSettings() didn't need it, since the JDBCReader calls setSettings() on both the user defined one and the default. It should probably do the same for configure().

By the way, I didn't run into this last time I tried this (earlier this year). I think because I was using DB2, which is down at the moment, so I can't verify.

max · **Posted:** Thu Sep 24, 2009 6:37 am

put the suggested patches in jira.