JPA solution, EE, hibernate entity 3.3.0,

Hey all,
I'm having some problems with my expectations I think. I'm working with regular java 1.4 entity/dto, and mappings are only with orm.xml file (no annotations).

I have a many-to-many mapping between two entities. The entities each have their associated List fields for the other entity.

If I set the List field to null, it deletes the mappings.

By default, I thought it was NOT supposed to do this, and that you had to explicitly set <cascade-delete>. So, tried both without <cascade> for default behavior, and then again with empty <cascade></cascade>, both with the same effect.

Is this behavior working as intended, and if so, how can I *disable* cascade-delete using orm.xml?

That's the right behaviour. Cascade is about how actions should be treated in an object graph. So if you have a parent with children and cascade is set to delete, deleting a parent will delete all its children. However, the association itself is a subject of who owns the relation. In JPA world this is dictated with mappedBy attribute. So the side that has mappedBy does NOT own a relation and if you set the relation to null from the mappedBy side the relation is not deleted from database. However, setting the side that doesn't have the mappedBy attribute to null will remove the relation from database.



Farzad-

Thanks farzad, I think I had my terminology confused then.

So the challenge is how to prevent the relation/association from being removed, if someone did an update while setting the field to null.

These are many-to-many mapping relations. The individual parents could be updated separately from the mappings, so when a parent gets updated right after a mapping gets updated, the mapping gets lost.

I would like parents to update themselves, but not update the relations/associations.

I would be able to give a solution if I know your use cases. However, why do you set the relation to null? This is not so common to call parent.setChildrent(null) if you are only updating the parent object itself.


Farzad-

Integrating with some custom Client UI code.

I purposefully left out the get/set on the List fields so the Client UI would not modify those relations, but it is kept within the private List fields (I have it set to FIELD access).

The general problem with a Parent entity updating right after a mapping has been updated is a big concern.

The null issue is related to the technology integration point -- they create a new entity, set the fields equivalent to the old entity (including the primary key) and send it for update. Since the association List fields are not visible, they do not get set (the client UI doesn't know about them anyway).

The null/technology integration is a moot point, as the direct challenge is some way to prevent the association from being updated by the parent object(s). The mappings are created externally outside of this application.

The work-around would be to re-populate the associations just before the update, but that seems kinda silly to me.

The other way around. I think a better solution is to send another object to client. This way the server side code can look up a parent and set the relevant fields. This is an extra step in your sequence diagram but this is somehow a corner case scenario for hibernate and one will anyway have to write some extra code.



Farzad-