ignoring collections on merge()

[gavinking]

After much discussion surrounding this issue, I'm convinced that a very common need, that we simply don't really address at all today is the need to "trim" the object graph that is considered by merge(), based on transaction-specific considerations. (Think of it as almost like the inverse of the problem solved by EntityGraph or fetch profiles.)

Currently, you have some decent control over this via the CascadeType, but that has some problems:

1. It's a global setting: if you need control at the transaction level you have to turn cascade merge off and explicitly merge each entity.
2. It doesn't give separate control over the entity and its collections: if you merge the entity, all its collections get merged.
3. Hibernate, since ancient times, takes the attitude that null means an empty collection, not an uninitialized collection, so you can't just null out the collection when you want it to be ignored. This is especially uncomfortable for people who trim object graphs for serialization/deserialization.

Note that none of these sources of discomfort is specific to unowned vs owned collections; the listed problems apply equally to both sorts of mapping.

Now, we've recently kicked around a few different ideas for this, and the ones which I think most directly attack the problem are:

1. Adding some sort of an additional argument to merge() that would let the program specify which collections to ignore, either via a callback, or by saying "ignore nulls" or even in principle with something like an EntityGraph.
2. Providing a way to replace a collection reference with an uninitialized proxy, since merge() already ignores uninitialized collections.

I had an inkling that 2 was already possible, just by new-ing a PersistentList or PersistentSet or whatever, and based on my initial testing that seems to be right. That is to say, it's already possible in Hibernate today, and has been for many years. Indeed, now that I think about it, I do seem to recall a user long ago telling me that they were doing that in their system. It's very likely that other users figured that out for themselves.

On the other hand:

• PersistentList or PersistentSet are clearly marked as internal APIs.
• We certainly don't document that this is possible, and surely many users did not figure it out before giving up.

Now, given that 2 is a way-lower-impact solution than 1, and works for people using the plain EntityManager API, and is also in some ways more flexible, I'm now inclined to think that it's really the path we should take at least for now. I propose:

• Adding APIs to the Hibernate class that do nothing more than new PersistentXxx() in a blessed way.
• Also adding a method Hibernate.uninitialize() to empty out the collection proxy.

Now, this solution is perhaps slightly less comfortable for users than just setting a collection reference to null, but frankly it's far more consistent with the perfectly-reasonable semantics that Hibernate has had for many years, and has, as I say, a very low impact. And it avoids opening up any cans of worms with respect to the JPA spec.

Note that I have not put much thought into the conceptually-similar problems affecting @XxxToOne associations, because the discomfort is much less acute there, and because I strongly suspect that the solution is entirely analogous: we could add a function a lot like getReference() to the Hibernate class, that gives a detached proxy for a class. I've been talking about collections above, but I think you could apply same reasoning to entity references.

[gavinking]

Also adding a method Hibernate.uninitialize() to empty out the collection proxy

I realized this is a bit harder than it looks at first blush. It's great for detached collections, but for attached collection it's a bit sorta nasty in the sense that it throws away unflushed changes. And for to-one associations we don't have a good reliable way to implement this, since we don't always have proxies in the object graph.

So I guess there's good reasons why this method doesn't already exist.

[gavinking]

This was done in H6. (There are new static methods on the Hibernate class.)