Does anyone have any ideas why I can't specify the primary key for my table with the following hibernate.reveng.xml for the ant taks <hbm2hbmxml>? The task will generate Mytable.hbm.xml with a composite-id with all the table's column as key-properties.

I've tried searching through the postings, and modifying the hibernate.reveng.xml file, but with no luck. I'm new to the hibernate tools project, so I apologize in advance if this is relatively obvious. This tool would be extremely useful if I could only get it to work...

Thanks,
PT

Hibernate version:
3.0.1

Mapping documents:
hibernate.reveng.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-reverse-engineering SYSTEM "http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd" >

<hibernate-reverse-engineering>

<table-filter match-name="quhdr" exclude="false" />
<table-filter match-name="qudet" exclude="false" />
<table-filter match-name=".*" exclude="true" /> <!-- Exclude DoNotWantIt from all catalogs/schemas -->

<table name="quhdr"> <!-- table allows you to override/define how reverse engineering are done for a specific table -->
<primary-key>
<generator class="assigned">
</generator>
<column name="QU_NUMBER"/>
</primary-key>
</table>

</hibernate-reverse-engineering>




Name and version of the database you are using:
INFORMIX-OnLine Version 7.20.UC4


Debug level Hibernate log excerpt:
[hibernatetool] 22429 [main] DEBUG org.hibernate.cfg.JDBCBinder - Finding columns for com.biz.quhdr
[hibernatetool] 22677 [main] WARN org.hibernate.cfg.JDBCBinder - The JDBC driver didn't report any primary key columns in quhdr. Asking rev.eng. strategy
[hibernatetool] 22678 [main] WARN org.hibernate.cfg.JDBCBinder - Rev.eng. strategy did not report any primary key columns for quhdr
[hibernatetool] 22709 [main] DEBUG org.hibernate.cfg.JDBCBinder - Calling getExportedKeys on org.hibernate.mapping.Table(com.biz.qudet)
[hibernatetool] 22737 [main] DEBUG org.hibernate.cfg.JDBCBinder - Calling getExportedKeys on org.hibernate.mapping.Table(com.biz.quhdr)

hmm - possible a bug.

try to use explicit schema/catalog names and see if that helps.

If it does or not, post your DDL and reveng.xml in a jira issue.

I tried explicit catalog and schema names, but that didn't help.

Thanks for your quick response Max. This looks like a really promising tool and I'll try to look into this further or will post a bug on JIRA.

what if you put the table name in uppercase ?

Setting catalog, schema and uppercase name helps for me. I use Hibernate Tools 3.1.0.beta3 as Eclipse 3.1 plugins and MS SQLServer.

Table FAHRZEUGE does not have a primary key. To get a simple id element in the mapping file i set it in hibernate.reveng.xml file:

I find that it suffices to provide only the capitalized schema, table name and primary key column name(s). reveng correctly infers the rest. E.g.:

<table schema="DBO" name="FAHRZEUGE">
<primary-key>
<column name="FAHRZEUG_ID"/>
</primary-key>
</table>

If the primary key override is not specified for a table without a primary key, then Hibernate 3.1b3 has a tendency to incorrectly return empty query results without an error message.

what does that last line mean ?

if you dont have a primary key then all of your columns get to be the key...

More specifically, records that include a null primary key column value are not recognized. E.g. if:

o Child has a composite key consisting of columns A and B

o a Child record has column values 'a' and null, resp.

o the Child record is referenced by a Parent record on foreign key column A

then parent.getChildren() will not include the record.

I don't know if this is a known bug or has been corrected. As mentioned, it occurs with 3.1b3.

A primary key cannot be null or partially null.

This is an artificial and unduly restrictive limitation for a composite key. Non-null opaque primary key attributes is a good database design goal. However, many of us do not have the luxury of always working with a well-designed database. The restriction should be that at least one of the primary key attributes is non-null and, of course, the composite key is unique. Is there a justification for the more stringent limitation that each of the primary key attributes is non-null?

how would you update or join with a row where part of the key is null ?

Think about how that sql looks like...horrific

update ...
where a = 'a'
and b is null;

select ...
where ((r.a = t.a) or (r.a is null and t.a is null)) ...

A smart query builder would include the null clause only for nullable columns of a composite key.

At the very least, it would be useful if a warning were printed when a nullable primary key column is encountered in the mapping.

yes - horrific and will perform poorly on dbs where null is non indexable.
In any case, its opensource and contributions are welcome. It is not a priority for us to support it.

The performance hit would only be incurred on tables which have nullable primary key columns. Furthermore, the use case is such that a join on such a composite key is rare. Usage of such a table is dominated by query on the table attributes or a non-null foreign key.

Clients have a reasonable expectation that a Hibernate query will either return the correct result or tell them why it cannot do so. This is a clear case where Hibernate neither returns the expected result nor issues a warning.

I'll pass on the invitation to contribute a patch. I've contributed a fair amount of open source and recognize that one should do so only when committers think the effort is worthwhile.

Thanks for the explanation. At least the limitation is captured in a forum. Hopefully, users will investigate and work around the limitation rather than regard Hibernate as buggy for legacy schemas, which unfortunately is the more typical response.

you did not read my answer correctly, I said it was not a *priority* for us because we have tons of other stuff that needs to be done and only so much time. If you contribute a patch that solves this problem then we will commit it.

But I will definitly always recommend fixing the broken data.