I can start integrating this code into your wip/6.0 branch. Are there any
fundamental changes you would like to see before I integrate, or should I
integrate as is?
On Fri, Apr 1, 2016 at 12:14 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
I do like the proposal. Awesome job on the gist. I'll look over
over the next few days.
On Thu, Mar 31, 2016 at 3:05 PM Gail Badner <gbadner(a)redhat.com> wrote:
> Replying for consideration for 6.0.
> On Mon, Feb 8, 2016 at 6:12 AM, Steve Ebersole <steve(a)hibernate.org>
>> This is going to have to wait post-5.1 as I mentioned earlier if this
>> was not ready prior to last week.
>> I have just too much on my plate to look at this over 2 days.
>> On Mon, Feb 8, 2016 at 12:29 AM Gail Badner <gbadner(a)redhat.com> wrote:
>>> The POC  assumes that we only need a single OperationContext for each
>>> type of operation. OperationContextManager has a Map of
>>> OperationContext by
>>> OperationContextType. Each OperationContext object is lazily created on
>>> first occurence of the corresponding type of operation.
>>> Currently, when an operation is initiated (e.g., by Session.merge(
>>> )), OperationContextManager  does the following:
>>> - calls ManageableOperationContext#beforeOperation, which puts the
>>> OperationContext "in progress";
>>> - executes the operation, which performs cascades according to mappings;
>>> - calls ManageableOperationContext#afterOperation, which puts the
>>> OperationContext in an invalid state that is "not in progress".
>>> When an operation cascades to other entities, the same OperationContext
>>> Obviously, OperationContextManager needs to know if an operation is
>>> "top-level" (meaning that the operation is on the original entity,
>>> cascaded). In the POC, if the relevant OperationContext is not in
>>> at the time that an opeation is initiated, then OperationContextManager
>>> assumes that the operation is top-level. If the OperationContext is "in
>>> progress", then OperationContextManager assumes that this is a cascaded
>>> I am not sure this is always correct. Can anyone think of a case where
>>> could break down?
>>> In the POC, the following EventSource methods that contain an argument
>>> the operation cache has been deprecated and is no longer used because
>>> contents of that argument has been moved into an OperationContext:
>>> public void merge(String entityName, Object object, Map copiedAlready)
>>> public void persist(String entityName, Object object, Map
>>> public void persistOnFlush(String entityName, Object object, Map
>>> public void refresh(String entityName, Object object, Map
>>> public void delete(String entityName, Object child, boolean
>>> isCascadeDeleteEnabled, Set transientEntities)
>>> Before the POC, it was the above methods that indicated that it was not
>>> top-level. If it turns out that having a single OperationContext is not
>>> valid, then there needs to be some other way to determine if the
>>> was top-level.
>>> I had originally planned to use PersistenceContext#getCascadeLevel ==
>>> 0 to
>>> indicate an operation was at the top-level, but I found that won't work
>>> some operations. For example, the cascade level for a top-level delete
>>> be > 1 when deleting orphans due to merge or save-or-update operations.
>>> Another example is that cascade level is not 0 on top-level
>>> while flushing.
>>> I have some ideas to work around this, but I didn't want to get too far
>>> down that path if it wasn't an issue.
>>> On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner <gbadner(a)redhat.com>
>>> > I've created a gist with an overview of the design:
>>> > https://gist.github.com/gbadner/f0e635e8fba7b84af233
. I will add a
>>> > section tomorrow about possible shortcomings.
>>> > Here is my POC:
>>> > https://github.com/hibernate/hibernate-orm/compare/master.
>>> > . Although no tests fail, the approach may be too simple to model
>>> what is
>>> > necessary.
>>> > At this point the POC is squashed down to 1 commit:
>>> > https://github.com/hibernate/hibernate-orm/commit/
>>> > Have a look and feel free to comment.
>>> > Thanks,
>>> > Gail
>>> hibernate-dev mailing list