thanks for this most valuable article! I’ve been struggling with managing bidi associations for a long time now. After reading your article I radically changed the design of my entities and can only see advantages.

So my advice is: Collections/Maps are EVIL! Wherever you can (and this is in most cases). Avoid their usage!

The reasons are not quite related to mapping the entities to the database but due to the fact that correct usage of Collections/Maps is far more complicated than one would expect on the first sight.

1. The interface types (Collection, List, Set etc.) do not implement Serializable. If you want your entities be Serializable (and according to Hibernate docs you should want that). They allways need a special treatment. That means extra effort.

2. When using the Collection types that guarantee uniqueness (Map, Set) you will have to ensure that changes to values in your entieties do not affect the result of hashCode() and equals(). When using their sorted variants (SortedSet, SortedMap) the result of compareTo() or the Comparator have to be taken care of too. If the changes affect those, you will have to deal with that. E.g. pull the entity out of the collection, change the attributes, put it back in). That is extra effort and might even result in additional DELETE/INSERT statements (allthough I havent investigated that).

3. Collections bloat your code. To deal with them you will have to implement methods for adding, checking containment of, retrieving, and deleting elements as well as decorating them unmodifiable. And you must (lazily) initialize them. That’s a lot of methods! Far more complicated compared to the getter (and possibly setter) of the child entity.

The only drawback is the one that you allready mentioned (you can only find children through your data acces layer).

As for dealing with large collections. You seldomly need to fetch the whole collection. On a standart GUI you can display an amount of -let’s say- 50 elements wihtout scrolling. Most websites (mine too) use a pager for this situation. So I’m thinking of configuring fetch size and using scrollable result sets. But haven’t made that yet.

Cheers nillehammer

In the context of DDD I am starting to feel avoiding one-to-many associations between Aggregates (Roots) and using queries instead is indeed the safest thing to do.

Within the same Aggregate it’s probably ok.

Good insight. Thanks.

Lionel.

One problem exists though: because it is so easy to set up @OneToMany associations and it makes traversing the object graph easier, you are likely to end up with @OneToMany associations where you don’t want them later on. In fact, what might be small set of data when you start a project, might end up becoming a large set when actual data flows through the program. So the safest thing of all would be to avoid @OneToMany associations altogether. Hmm…

After all of this time, I have finally come to the simple conclusion that using one-to-many relationships for large collections is a just a bad idea. Even if you are to get around the issues with lazy-loading, you still face the problem of the memory usage for the collection. We use EclipseLink’s “SoftWeak” caching strategy in general. But when one object holds a collection to hundreds or thousands of other entities that otherwise have only a weak reference, garbage collection is severely hampered. I basically draw the line at around 100 objects. Any relationship that would involve more than 100 objects is not a candidate for a collection mapping. This is not a hard and fast rule, but I have found that the cost of the extra DAO and service layer coding outweighs the hassles of dealing with these performance issues.

In that case one way to do it is to define the child as a separate entity with a composite primary key defined with the @IdClass annotation.

Is that what you are looking for? If not, please post the definition of your schema.

As I am new to jpa, please forgive the simplicity of the question. I have the following problem:

How can I read a collection of strings from a child table that references the parent table by a FK ? The database is legacy and I can not change it. This seems likes such a basic operation and it frustrates me that I do not know how to do it in JPA.

Thank You,
MPK

One remark about the last paragraph where you mention that the queued operations need to be propagated to the underlying set before the transaction is committed: this is not necessary when the set is not the owning side of a bidirectional relation (i.e.. when the set has the mappedBy field set on the @OneToMany annotation). And in most cases that is so.

In any case, you’d rather not do this last-minute propagation because initializating the set is expensive (the reason we are bothering with this pattern anyway).

But there are some gotchas, like ensuring any decorating collections are created only after the field injection of the ORM-managed fields has taken place. I guess @PostConstruct could be used for that, but that’s a bit ugly. Or you could use double checked locking.

So something like

class Entity {
  Collection persistedCollection;
  transient Collection lateLoadingPersistedCollection;

  @PostConstruct
  void createLateLoadingCollections() {
    lateLoadingPersistedCollection = new LateLoadingCollection(persistedCollection);
  }

  Collection getPersistedCollection() {
    return lateLoadingPersistedCollection;
  }

}

or

class Entity {
  Collection persistedCollection;

  // let's pretend closures made it to Java 7
  transient LazyField lateLoadingPersistedCollection =
    new LazyField({ new LateLoadingCollection(persistedCollection) });

  Collection getPersistedCollection() {
    assert persistedCollection != null;
    return lateLoadingPersistedCollection.get();
  }

}

where LazyField is just some wrapper around some double-checked locking lazy instantiation code.

Because both examples rely on returning the decorated collection from the getter, this presumably wouldn’t work with property access, by the way (but I guess that wouldn’t bother you).

The LateLoadingCollection itself would just be a decorator around the real, ORM-managed collection that would intercept the add and remove methods (storing the values in a queue or whatever) and would simply merge and then delegate to the underlying set in all other cases, which would result in a load whenever e.g. the iterator was called.

A key question here would be whether there is some guarantee that get (or any of the other methods that would result in a merge of any queued changes) would be called when an entity is persisted. Otherwise, changes to the underlying persistedCollection might not be saved, of course…