Maintaining relationships in JPA 2.0

Question

I've been using JPA 2.0 for a while but, sad to admit, I haven't had enough time to learn it properly. It seems like I lack the basics of how to work with Entity Manager.

Moving one step at a time, I'd like to first ask you about maintaining relationships between mapped entities. Of course I know how to create mappings between entities, different types of available associations ( OneToOne , etc.) and how databases work in general. I'm purely focused on maintaining it via Entity Manager , so please do not send me to any kind of general knowledge tutorial :-).

The questions are:

1. Am I right that as a programmer I'm responsible for maintaining (creating/updating/removing) relationships between instances of entities?
2. Do I have to always update (set to null, remove from collection, etc.) instances by hand?
3. Plain SQL can set entities to NULL on deleting, but it seems like JPA can't do such a simple thing. It also seems like a burden to do it manually. Is there a way to achieve that with JPA?
4. If I have OneToMany relationship and set to NULL the entity on the Many side of the relationship. Then I persist the changes in a Set by saving the entity on the One side. Do I then have to update the entities in the Many side and set association to NULL in each instance? Seems pure silliness for one-directional bindings!

Thanks in advance!

Answer 1

The main thing you need to investigate is the different options you have when mapping on entity. For example in the next piece of code the cascade all option will instruct jpa to delete the child list when the parent is deleted.

@OneToMany(fetch = FetchType.LAZY, cascade = { CascadeType.ALL }, mappedBy = "parent")
private Set<Child> events = new HashSet<Child>();

Answer 2

1. Yes. You maintain the object tree and modify it to look like what you want.
2. Yes and no. If you want the entity to reference null, then yes. For instance, if you are removing one Entity, then you should clean up any references to it held by other entities that you are not removing. A practical example: its good practice to let an Employee know his/her Manager has been let go. If the Employee is going to stay, it should either have its manager reference nulled out or set to a different manager, before the current manager can be removed.
   If the employee is going to be removed as well, then cascade remove can cascade to all the Manager's subordinates, in which case you do not need to clean up their references to the manager - as they are going away too.
3. I don't quite understand what SQL is setting to null. Deleting removes the row in the database, so there isn't anything to set to null. Cleaning up a reference shouldn't be that difficult in the object model, as JPA has a number of events to help such as preremove preupdate etc. In the end though, the problem is with your java objects. They are just java objects, so if you want something done, your application will need to do it for the most part. JPA handles building them and pushing them to the database, not changing the state for you.
4. Yes and no. If you set up a bidirectional relationship, you must maintain both sides as mentioned above. If you set the child's parent reference to null, you should let the parent know it no longer has a child, wouldn't you? Your parent will continue to reference its child for as long as that Parent instance exists. So even though the database is updated/controlled through the side that owns a relationship, the object model will be out of synch with the database until it is refreshed or somehow reloaded. JPA allows for multiple levels of caching, so it all depends on your provider setup how long that Parent instance will exist referencing a Child that no longer exists in the database.