Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-13166

Investigate better option to materialize sub objects in JPA

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.6
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • 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.

        Attachments

          Issue Links

            Activity

            Hide
            mztaylor 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
            mztaylor 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:
                kbtaylor Kristina Taylor (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: