I'm using mysql 4.0.13

I have a set that is mapped using composite-element

When I load the enitity, modify an attribute, and flush

The entity row gets updated
but the set's rows are deleted / reinserted
even though I didn't touch the set

Why is this?
Should I change to a list ?

It didn't do this when I had the set mapped using many-to-one

I'd like to stick with composite-element since the set reallly is
of value objects not of entities

btw 2.1 beta is letting me query using attributes of the
composite-element, very nice :)


code:
public static void updateHawb(Long id) {
try {
Session session = HibernateSingleton.getSession();

IHawb hawb = (IHawb)session.load(SoloHawb.class, id);

printHawb(hawb); //Iterates set but doesn't modify
hawb.setStatus("BLAH");

session.flush();

session.close();
} catch (HibernateException e) {
e.printStackTrace();
}
}

Implement equals()/hashCode(), as is required by the java.util.Set contract.

Doh!

Now that I actually looked at the Set java doc I'm seeing
that using mutable types with a Set can be problematic
if an instance is modified after being added to the Set

So now really I'm wondering if it would be better to use a List

In that case I could modify an instance in the list
and I would not need to implement equals()/hashCode()

Is that correct?

Well, you can try using a <bag> mapping...


or, even better, an <idbag>?


mmmm ..... <idbag> ..... I like 'em ....

I've tried implementing equals()/hashCode()
on my value object

but the set's rows are still being deleted / reinserted


Could this be because the map uses a type that extends
from the type I implemented equals()/hashCode() in ?

Nope; because it doesn't ;)

This *does* work (in fact I tested it just recently). Still the most likely explanation is that your equals()/hashCode() is wrong.


(Another possibility is that you don't return the same Set instance that Hibernate assigns to the setter method. Check your get/set pairs for "funniness".)

What I meant was that I have an inheritance hierchy
for ReferenceNumber and the map for this particular
entity maps to a subclass of ReferenceNumber

while ReferenceNumber is the class I actually
defined equals()/hashCode() on


I believe it works, I'm just doing something wrong

the get/set for the Set is really simple

code:

public Set getRefs() {
return refs;
}

public void setRefs(Set set) {
refs = set;
}


So it must be my equals/hashCode on ReferenceNumber

public boolean equals(ReferenceNumber ref) {
if(ref.refNum.equals(refNum))
if(ref.refType.equals(refType))
return true;
return false;
}

public int hashCode() {
return 1;
}


refNum and refType are Strings

I cheated on the hashCode, but I thought that would only affect performance

When I added an index column and mapped using list
the insert / delete problem went away

However, I tried manually deleting the 0 row
and that caused Hibernate to barf when trying to
iterate the List
So that method is probably out, as I can't garantee
legacy applications won't do stupid stuff like that


I looked in the doc for idbag
the doc indicates that identity generation is not supported
but with MySql this would be that natural thing

In fact this how the existing schema is setup, with
an auto_increment surrogate key


I'm starting to wonder if I should just go back to using
many-to-one

I'd need to hide the management of the parent attribute behind
a convienence method of the parent entity, but I guess that
would be my only problem then

Dude!


It is equals(Object) that you need to define!!


Java does not use runtime type information when resolving method overloads.

DOH!

I've learned that one the hard way before.
Apparently not well enough.


Thanks for holding my hand.

Anyways new day, new stuff.

The mapping works
both as composite-element set
and as one-to-many set

My question now is, with queries that use
element attributes working even
with composite-element, is there any reason
to use one-to-many in a situation where
the life-cycle of the set is tied to the parent?

The only thing I can think of is if one were to want to
query for child objects independant of loading the parent
but then the inverese relation would have to be lazy ?



I feel like I'm on the verge of actually groking hibernate.
I'm really happy with the power it gives me.
Polymorphic queries are awesome!

There are three reasons to not use composite-elements:

(1) you can't really query them in an ad hoc fashion
(2) they can't own collections
(3) they can't be referenced by other entities

for a typical parent/child relationship, they might be quite a good solution.