I think I see the issue. When a JDBC implementation returns NULL for FK_NAME (as allowable by the getExportedKeys() JDBC spec -
http://java.sun.com/javase/6/docs/api/j ... ang.String) ), the hibernate code to generate a bogusFkName has a bug.
Code:
package org.hibernate.cfg.reveng;
public class JDBCReader {
protected ForeignKeysInfo processForeignKeys(DatabaseCollector dbs, Table referencedTable, ProgressListener progress) throws JDBCBinderException {
short bogusFkName = 0;
// first get all the relationships dictated by the database schema
Iterator exportedKeyIterator = null;
log.debug("Calling getExportedKeys on " + referencedTable);
progress.startSubTask("Finding exported foreignkeys on " + referencedTable.getName());
try {
Map exportedKeyRs = null;
exportedKeyIterator = getMetaDataDialect().getExportedKeys(getCatalogForDBLookup(referencedTable.getCatalog()), getSchemaForDBLookup(referencedTable.getSchema()), referencedTable.getName() );
try {
while (exportedKeyIterator.hasNext() ) {
...
short keySeq = ((Short)exportedKeyRs.get("KEY_SEQ")).shortValue();
...
if (keySeq == 0) {
bogusFkName++;
}
if (fkName == null) {
// somehow reuse hibernates name generator ?
fkName = Short.toString(bogusFkName);
}
...
By my reading of
http://java.sun.com/javase/6/docs/api/j ... ang.String) the keySeq really shouldn't have anything to do with generating a unique bogusFkName.
Therefore, I think the guard if (keySeq == 0) should be removed and bogusFkName should be incremented every time.
Login
FAQ
Search
