I'm very new to Hibernate, and I've run into an issue dealing with legacy data (in this case DB2/400 running Mapics manufacturing software).

I have a table which has no native primary key, and I am unable to build a unique composite key since in a few cases entire rows are duplicated.

I'm using <composite-id>, and I understand implementing my own equals() and hashCode(). However, since there are duplicate rows, I'm sort of stuck.

It seems if I code equals() and hashCode() to compare at least several of the most important columns, Hibernate returns duplicate Java objects in the list representing the duplicate rows. Is this what I should expect? I suppose I could do a distinct selection (or otherwise omit the dupes).

This table will be read-only, and I'm basically just reading it to present a list of historical data.

Does Hibernate absolutely require a primary key in the case of a read-only table? I of course don't have to use Hibernate, but there are many features I like and would like to utilize.

I've tried omitting <id> and <composite-id> from my mapping file, but I get a SAX parse error (not surprisingly):

Caused by: org.xml.sax.SAXParseException: The content of element type "class" must match "(meta*,(cache|jcs-cache)?,(id|composite-id),discriminator?,(version|timestamp)?,(property|many-to-one|one-to-one|component|dynamic-component|any|map|set|list|bag|idbag|array|primitive-array)*,(subclass*|joined-subclass*))".

I'm running Hibernate version 2.1.6.

Thanks,
Shawn

I've typically added a new column, delayed the creation of a unique constraint, went through and assign each row a number, and create a constraint after that.

You can easily make it a sequence (for those DBs that support it) and start the sequence after the last number you assigned, then Hibernate can do the automatic creation for you.

Jeff

If I could add a new column, that would be fine, but unfortunately in this case altering the schema is not really an option (many legacy apps use this table). Again, I am not going to update this data, so Hibernate is out of the picture in that regard.

Since I am new to Hibernate and am trying to understand more of the internals, I mainly wanted to know 1) Does Hibernate absolutely always require a primary key, and 2) Is it expected behavior for Hibernate to return the same object instance for items in a list() which evaluate as equal?

Thanks,
Shawn

Just map a column or a set of columns uniquely identfying a column as the id.

As I mentioned, I'm using <composite-id> to do this, and again the difficulty is that it is not possible to generate a unique composite key (since entire rows are sometimes duplicated).

Anyway, I will assume the answers to my questions are 1) yes and 2) yes, unless someone can confirm otherwise.

Thanks.

Hibernate will not work on a table with no primary-key candidate, as this is a totally broken relational model. If you can't clean up your model somehow (for example create a distinctifying view) you won't be able to use Hibernate.

I understand this model is pitiful, but unfortunately I can't do much about it. I can make this work satisfactorily enough by making several important columns part of the key, and in cases where those columns are duplicate it seems Hibernate gives me the same object (so I wouldn't know if other less-important columns happened to be different).

Thanks for confirming what I was observing. In read-only cases, I am a little surprised Hibernate doesn't have a mechanism however to just give me a result set from a query, regardless of whether there happens to be a primary key candidate.

I'm not picking on Hibernate, I'm just trying to understand how Hibernate thinks. Can you explain why Hibernate insists on a primary key if I don't plan to update the table (or point me to a reference somewhere)? Is it to avoid redundant object creation? Is it for performance? Is it to completely eliminate the possibility of update? I've read everything I can find, with the exception of Hibernate in Action (which I plan to get very soon).

Fortunately, this one table is an exception. Regardless, in real life this crap happens more often than one might think or like.

Thanks again,
Shawn

delete duplicates and use all fields as key, there is no use cases for duplicates anyway.

Why does Hibernate require a primary key?
I am having the exact same problem, and I thought that using a <bag> insetad of a <set> was intended to let me map these cases.

Updating a bag deletes all rows and inserts all rows again, removing the need for an uniqe ID as far as I can see. As I am only going to read from the bag, this has no performace penalty for me.

Bag looks promising, but when the class that I am mapping with the bag _has_ to declare a primary key I cannot see a sensible use for <bag> anymore.

Am I missing something?

Regards,
Karl Ivar Dahl

The apparent solution seems to be using <composite-element> in the <bag>. Composite elements does all I need, without the need for a defined primary key.

you guys with duplicate rows - how do you update/delete one row and not the others ? How do you distinguish these rows ?

just curious ;)

The <bag> implementation deletes all content of the bag on an update,
then inserts everything that is left. So when an element is removed from
the bag, hibernate/DB does not have to know which one it was. It is
definitively a performance killer, but I suspect most uses of bags are
read-only. It is probably other 'legacy' applications that are providing the
data.

eh ? how was that an answer ?

having in a bag doesnt change how your queries will work against the tables ? still no way of distincting the different rows...

Seeing that you are part of the Hibernate theam, you probably know how <bag> is implemented better than me :-)

I'll tell a bit of my scenario when it is needed:
I am importing (with Hibernate) a lot of sales transaction logs for a national
transport company. Some of these transactions can be identical (same ticket, same destination etc).
During import a series of chekcs and relation identification are done. If the transaction passes, the data is copied to a
'domain' object with proper object relations that is persisted by Hibernate and used by the rest of the system.

My 'domain' naturally has syntethic keys and relations, but the data I'm importing definitively has not.
So when i'm importing these data I'm basically traversing a <bag> with 'import' objects, copying them to
'domain' objects and persisting them. Hibernate then gives the domain objects an identity
from a DB sequence.

As for the need of identifying which element I would like to delete in a bag, the answer is I don't care which one I
delete as long as the number of identical rows decreases by one :-)

As I stated in a previous post I can probably solve this by using a <bag> with composite-elements.

From the Hibernate reference:


This leads me to believe that Hibernate does not have to know which row I am altering when I pick a random element from the bag. It just empties the bag and saves all elelents as they were new, no matter how small the change to one of the elements was.