Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-13166

Investigate better option to materialize sub objects in JPA

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.6
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-3914Materializing JPA/Hibernate queries causes strange exception
      KULRICE-14110JPA Performance of Referenced Entity (Child Data Objects) - KRMS
      KULRICE-14111JPA Performance of Referenced Entity (Child Data Objects) - KEW
      KULRICE-14112JPA Performance of Referenced Entity (Child Data Objects) - KIM
      KULRICE-13994Copy maintenance function needs option to copy readOnly fields
      KULRICE-46Investigate SSO options for Rice
      KULRICE-4738Tools for initial creation of KRAD objects
      KULRICE-13088ObjectUtils deep copy related methods need to be ported over to JPA
      KULRICE-10360Investigate a reset option for dialog groups
      KULRICE-3913JPA/Hibernate proxies confuse KNS Inquiry
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      In the TransactionalDocumentControllerServiceImpl.copy method, we put in a magic number (3) that has worked for a long time to help materialize objects in order to copy them from one maintenance document to another. This practice, however, is dated, and now that we are on JPA, we have a number of options available to us that will not depend on this. We need to figure out a better strategy, implement it, and test it.

      More from Jonathan:

      Depth matches a constant used by the KNS. So, for equivalency, it's correct. As far as a good solution goes, not so much.

      But, this would cause a DB load for every referenced object in the tree. And, it has no sense of potential looping references, so we need to stop it somewhere.

      At the time this number was chosen (probably back in 2007), it matched KFS' needs.

      IMO - the framework probably should not be coding a number. It would be more that it should:

      1) Traverse all updatable objects from the parent.
      2) Refresh all the direct non-updatable references on the parent and updatable children.

      ...While I don't think [the work] would be that complex now - I do think that there could be side effects, since it could potentially cause there to be deeper (in the case of a complex object model) or shallower (in the case of a single level object model) refreshes.

      I don't really think that will be a problem, since the newly loaded objects should pull child objects automatically. But I do know of places in KFS where workflow traverses paths like "document.sourceAccountingLines[0].account.subFundGroup.subFundGroupTypeCode"

      In the new "model", we would only refresh down to the Account object, leaving the SubFundGroup as a lazy-loaded proxy. Technically, the EL system should handle this, but I think we would need to test.

        Issue Links

          Activity

          Hide
          Martin Taylor (Inactive) added a comment -

          Reviewing EclipseLink's CopyGroup functionality for ideas: http://www.eclipse.org/eclipselink/api/2.1/org/eclipse/persistence/sessions/CopyGroup.html

          Show
          Martin Taylor (Inactive) added a comment - Reviewing EclipseLink's CopyGroup functionality for ideas: http://www.eclipse.org/eclipselink/api/2.1/org/eclipse/persistence/sessions/CopyGroup.html

            People

            • Assignee:
              Unassigned
              Reporter:
              Kristina Taylor (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Structure Helper Panel