I do wonder if OperationContextType should not be integrated into EventType. I hate repeatng this set of enumerations. Something like https://gist.github.com/sebersole/2a4af882d0a61696dce39d242023add0
Not specific to this PoC but one thing I would also like to see is the ability to know the EventType/OperationContextType we are currently processing (if any). On Tue, Aug 30, 2016 at 3:40 PM Gail Badner <gbad...@redhat.com> wrote: > Hi Steve, > > 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? > > Thanks, > Gail > > On Fri, Apr 1, 2016 at 12:14 PM, Steve Ebersole <st...@hibernate.org> > wrote: > >> I do like the proposal. Awesome job on the gist. I'll look over the >> code over the next few days. >> >> On Thu, Mar 31, 2016 at 3:05 PM Gail Badner <gbad...@redhat.com> wrote: >> >>> Replying for consideration for 6.0. >>> >>> On Mon, Feb 8, 2016 at 6:12 AM, Steve Ebersole <st...@hibernate.org> >>> wrote: >>> >>>> 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 <gbad...@redhat.com> wrote: >>>> >>>>> The POC [1] 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 the >>>>> first occurence of the corresponding type of operation. >>>>> >>>>> Currently, when an operation is initiated (e.g., by Session.merge( >>>>> entity >>>>> )), OperationContextManager [2] 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 is >>>>> used. >>>>> >>>>> Obviously, OperationContextManager needs to know if an operation is >>>>> "top-level" (meaning that the operation is on the original entity, and >>>>> not >>>>> cascaded). In the POC, if the relevant OperationContext is not in >>>>> progress >>>>> 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 >>>>> operation. >>>>> >>>>> I am not sure this is always correct. Can anyone think of a case where >>>>> this >>>>> could break down? >>>>> >>>>> In the POC, the following EventSource methods that contain an argument >>>>> for >>>>> the operation cache has been deprecated and is no longer used because >>>>> the >>>>> 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 >>>>> createdAlready) >>>>> public void persistOnFlush(String entityName, Object object, Map >>>>> copiedAlready) >>>>> public void refresh(String entityName, Object object, Map >>>>> refreshedAlready) >>>>> 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 >>>>> operation >>>>> 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 for >>>>> some operations. For example, the cascade level for a top-level delete >>>>> can >>>>> 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 >>>>> save-or-update >>>>> 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. >>>>> >>>>> Thanks, >>>>> Gail >>>>> >>>>> [1] >>>>> >>>>> https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java >>>>> [2] >>>>> >>>>> https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java#L132 >>>>> >>>>> >>>>> On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner <gbad...@redhat.com> >>>>> wrote: >>>>> >>>>> > I've created a gist with an overview of the design: >>>>> > https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a >>>>> new >>>>> > section tomorrow about possible shortcomings. >>>>> > >>>>> > Here is my POC: >>>>> > >>>>> https://github.com/hibernate/hibernate-orm/compare/master...gbadner:HHH-10478-OperationContext >>>>> > . 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/3d0e2378cb998788b3205afb1e15c443c5ba77e8 >>>>> > >>>>> > Have a look and feel free to comment. >>>>> > >>>>> > Thanks, >>>>> > Gail >>>>> > >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
