8:50 a.m.
After fixing HHH-6848, Hibernate throws IllegalStateException when merging entity
'x' if it has references to 2 detached entities 'y1' and 'y2'
obtained from different sessions, and y1 and y2 represent the same persistent entity. In
other words, y1 != y2.
I've pushed some FailureExpected test cases to org.hibernate.test.ops.MergeTest that
illustrate this. [1]
Before fixing HHH-6848, one of the representations would be merged and the other would be
ignored (probably overwritten).
I'm looking into a fix that will restore this functionality as well as provide logging
for this situation. I'll discuss logging in a separate email.
Merging multiple representations that have equivalent state would be straightforward.
Things are more complicated when the representations do not have equivalent state. I'd
like to discuss and get feedback before fixing this.
I am a little leery about allowing multiple representations that are not equivalent to be
merged because data could be lost. I would prefer to throw an exception by default, and
then provide a flag to override this behavior as suggested in HHH-8570. I discussed
briefly with Steve E., and he preferred to address this concern by logging a warning.
Opinions?
In any case, here are 2 possible strategies:
1) The last one copied will "win". First, the state from one will be copied onto
a pre-existing managed entity or a new managed copy, then later when the merge operation
is cascaded to the other representation, a copy of its state will overwrite the managed
entity state.
2) The first representation detected will "win". The idea here is that y1 and y2
are both representations of the same entity; only 1 can be merged. When the first is
detected, the merge operation is cascaded to its associations with cascade=MERGE or
cascade=AL, then its state will be copied onto a pre-existing managed entity or a new
managed copy. When a later representation is detected, it's state is not copied and
the merge operation is not cascaded to its associations with cascade=MERGE or
cascade=ALL.
I think 2) fits in better With the way merge currently works.
A problem with 1) is that we won't know when we are processing the last representation
until all cascade-merges are finished. By then, the session may contain entities from
cascading the merge operation from the earlier representations. This could result in
persisting transient entities or updating entites that are only associated with earlier
representations.
With 2) we always know when we are processing the first representation and can more easily
skip cascading the merge operation for representations detected later.
Comments?
Thanks,
Gail
[1]
https://github.com/hibernate/hibernate-orm/blob/0118376f8efd9b35d8be815c8...
1:32 p.m.
I have had a chat with Gail on $subject and promised to give my
feedback.
First of, I would argue that the user is doing something relatively
wrong on my weirdo scale. I am not massively bothered with whatever
solution we end up choosing.
When the same state is present in both instances, you guys agreed to
consider it a no-op which Ia gree offers the best user experience.
About warn vs exception, I would prefer warn or even nothing (see below)
but I can see the benefit of a pluggable strategy.
Now the big questions are:
1. Should we take into account the first version of the entity and
ignore / warn / throw an exception on the followings
OR should we always override the state with the last version of the
entity encountered (and warn or throw and exception optionally)
2. Should this rule be the same when we are discussing cascading from a
single call / cascade tree to em.merge(x)
And when it comes from two subsequent calls to merge
em.merge(y1); em.merge(y2);
Unsurprisingly the spec does not mention this case explicitly but the
merge semantic indicates that the state of the entity provided is merged
into the state of the persistence context.
So my preference would be to last version wins which makes all situations similar.
I understand that cascading of merge could lead to the merge of entities
no longer associated with the entity that ends up in the database but I
prefer the simplicity of the rule leading to odd behavior is corner
cases than something complex to explain.
If we end up supporting the following behavior
y = em.merge(y1); //state if y1 copied in y
y = em.merge(y2); //state of y2 ignored and y keeps y1 state
I would be concerned it leads to a lot of misunderstanding and complains
from the users. And to me it would be against the spec as I read it.
Fundamentally merge is broken-ish and I tend to prefer the saveOrUpdate
moder which clearly throw an exception in case of conflicts like this.
But that's not the model that was chosen in JPA.
Emmanuel
On Tue 2014-04-08 2:50, Gail Badner wrote:
After fixing HHH-6848, Hibernate throws IllegalStateException when
merging entity 'x' if it has references to 2 detached entities 'y1' and
'y2' obtained from different sessions, and y1 and y2 represent the same persistent
entity. In other words, y1 != y2.
I've pushed some FailureExpected test cases to org.hibernate.test.ops.MergeTest that
illustrate this. [1]
Before fixing HHH-6848, one of the representations would be merged and the other would be
ignored (probably overwritten).
I'm looking into a fix that will restore this functionality as well as provide
logging for this situation. I'll discuss logging in a separate email.
Merging multiple representations that have equivalent state would be straightforward.
Things are more complicated when the representations do not have equivalent state. I'd
like to discuss and get feedback before fixing this.
I am a little leery about allowing multiple representations that are not equivalent to be
merged because data could be lost. I would prefer to throw an exception by default, and
then provide a flag to override this behavior as suggested in HHH-8570. I discussed
briefly with Steve E., and he preferred to address this concern by logging a warning.
Opinions?
In any case, here are 2 possible strategies:
1) The last one copied will "win". First, the state from one will be copied
onto a pre-existing managed entity or a new managed copy, then later when the merge
operation is cascaded to the other representation, a copy of its state will overwrite the
managed entity state.
2) The first representation detected will "win". The idea here is that y1 and
y2 are both representations of the same entity; only 1 can be merged. When the first is
detected, the merge operation is cascaded to its associations with cascade=MERGE or
cascade=AL, then its state will be copied onto a pre-existing managed entity or a new
managed copy. When a later representation is detected, it's state is not copied and
the merge operation is not cascaded to its associations with cascade=MERGE or
cascade=ALL.
I think 2) fits in better With the way merge currently works.
A problem with 1) is that we won't know when we are processing the last
representation until all cascade-merges are finished. By then, the session may contain
entities from cascading the merge operation from the earlier representations. This could
result in persisting transient entities or updating entites that are only associated with
earlier representations.
With 2) we always know when we are processing the first representation and can more
easily skip cascading the merge operation for representations detected later.
Comments?
Thanks,
Gail
[1]
https://github.com/hibernate/hibernate-orm/blob/0118376f8efd9b35d8be815c8...
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3678
days inactive
3679
days old
1 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Gail Badner