Hello

I've been reading the docs on composite id and all that stuff, and I could do with an example of where composite id is used along with an existing native id in order that saveOrUpdate works with objects that are passed up the the model tier.

Preferably there's an example using xdoclet tags, before anyone start RTFM type responses I am doing, but I'm a tad green when it comes to model tier development (more of a web tier person).

I want to do something like follows.

Address address = new Address();
address.setBuilding("1");
address.setStreet("Some Street");
address.setTown("Some Town");
address.setPostcode("HJ8 9UI");

List addressList = customer.getAddresses();
if(!addressList.contains(address)) {
AddressPeer.save(address);
}

...// AddressPeer
public static void save(Address address) {
//bla bla
session.saveOrUpdate(address);
}
..

At the moment save or update always inserts as is the default, and unsaved-value doesn't do what I want as it always saves or always updates thus I understand I need a composite key to identify an object in the absence of an ID. This sort of thing is probably obvious to some of you but not to me so easy on the "oh thats standard practice" or "thats simply this"..

Cheers Mark

I would recommand you to use <version unsaved-value="..."> if you're stuck with composite-id.

That's the easiest way to keep the saveOrUpdate feature intact.

Otherwise use an interceptor to build you business rules of save/update.

But I've no sample, I use surrigate keys.

Thanks for the response.

The problem with unsaved-value is that it still provided no means of checking equality without using the id . If it always updates then i cant use this for new items, while always inserting/saving is also no good as sometime there could be a match and thus i want to update.

I'm making progress with composite-id (at least i think so), it seems the right way to do what i want. I'll get there in the end, I'll post the solution when i'm done, so some other poor git doesn't have to undergo the pain :o)

Cheers Mark

hello Mark,

I have been following this thread since I too have been looking at composite keys. If you search for pretty old threads..from sept 2003 to Dec 2003, you will find lot material on composite keys. as for me, I decided to go the surrogate key way for each tables (even associative ones :))..but then I have the luxury of starting from sratch on the database side. Would be awsome if you could post your solution when you arrive at one.

Thanks

hi shishir (sorry if that's not your name)

suggogate keys, emmanuel seems to dig them also. I'll give google a go. All i want to do is be able to test for equality before an id is asigned (before its writen to the db). My concept of a surrogate key a key that you can generate based on the other field values to produce a unqiue field (corrent me if i'm wrong).

I get to do what i like with the db so i've the same luxury.

I've got as far as overiding equals and hash code, but as i expected hibernate wont be happy untill i map all the fields. The more i think about it the more a pain in the arse I see this being.

The additional problem is whether xdoclet tags cover this, but then I could just have them as merge resources.

don't i know you from the struts list?

cheers mark

Read the last section of http://www.hibernate.org/Documentation/EqualsAndHashCode

well...now that's a new perspective. Damm..there are so many conflicting ideas out there that I really get confused as to how to approach the whole issue.

From reading the article, Ennamuel, I believe we can maintain the id as a primary key, but override the equals/hashto to include the unique key and exclude the id. Do you forsee any problems with that? What if my class has just one primary key which is the id?


Yes Mark,you got my name right and we have met on the struts list, although, Hibernate has been keeping me pretty busy these days :).

I decided to go with the id as surrogate key in all my class since some of my associative classes have keys in them. Lacking the expertise and time to experiment, I decided to take the simple road (I think so ).

Thanks
Shishir

The real requirement is that you have to live wo conflict with the set lifetime.
If id is set, then using id seems OK in most business usage, if it's empty, then using the semi-unique key is mandatory. The real issue is the filling of new elements.

But I've not think enough on that subject.

I basically have come to the conclusion that you should not use the id property in your code at all. In fact in my code I try to make the getters and setters for it private as often as possible and stick to another unique identifier. Equals and hashCode of course have to use that identifier too. It only gets difficult if it gets really hard to find a unique property set.

Ids may be used as a "handle". They shouldn't be used for equals/hashCode - the business key should be used instead. There is a nice section in book about this.

Again sticking to the Address object by way of example.

I've over riden equals comparing all the properties i want to check

public boolean equals(Object obj) {
Address address;
if (obj == null) {
return false;
}

address = (Address) obj;

boolean result = false;
result = getBuilding().equals(address.getBuilding()) &&
getStreet().equals(address.getStreet()) &&
getPostalTown().equals(address.getPostalTown()) &&
getPostcode().equals(address.getPostcode()) &&
getCustomer().equals(address.getCustomer());
return result;

}

/* any old one should do */
public int hashCode() {
return getBuilding() == null ? 0 : getBuilding().hashCode();
}

naturally hibernate throws a null pointer as i haven't told it about the composite-id .. just fiddling with xdoclet merge dir at the moment to try and shoe-horn the right stuff into the generated mapping file.

but hopefully my thinking is along the right lines.

So probably we should try to get this communicated clearly on all relevant points, I think there are some contradictions around in the Wiki (for example we should probably change the wording of the Equals/HashCode page). I will go on and work on this if noone protests.

I added the essence of this section to the equals/hashcode page on the wiki.

But yes, the page needs some work, go ahead :)