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

Review auto-loaded relationships to data which is part of the document type definition

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0.1, KFS Release 3.0
    • Fix Version/s: Backlog
    • Component/s: Analysis
    • Labels:
    • Rice Module:
      KEW
    • Application Requirement:
      KFS, Rice

      Description

      There are a number of business objects in KEW which are used as part of workflow processing which have OJB references (non-proxied/auto-loaded) to the document type or children of the document type definition. These cause addition database overhead in the workflow engine which is not necessary since the document types (and all their child data) is cached centrally. (This cache is only purged when a document type document is completed or workflow XML is ingested.)

      These auto-loaded relationships should be reviewed to see if they (1) are used at all, and (2) can be replaced with smart getters which pull the information from the document type cache on access. (And store the reference locally so we don't need to reload from the cache.)

        Attachments

          Activity

          Hide
          jkeller Jonathan Keller added a comment -

          DocumentTypeAttribute has a non-proxied reference to DocumentType which is never used. This causes the document type to get re-loaded from the database for every attribute on a document. This property can be removed from the BO and the OJB configuration file.

          Show
          jkeller Jonathan Keller added a comment - DocumentTypeAttribute has a non-proxied reference to DocumentType which is never used. This causes the document type to get re-loaded from the database for every attribute on a document. This property can be removed from the BO and the OJB configuration file.
          Hide
          jkeller Jonathan Keller added a comment -

          The main workflow Process object also has this. It's currently using an anonymous join attribute - with no data element for the document type ID in the object. Changing this would require a change to the BO, to bring in the document type ID as a concrete attribute, so that it could be looked up from the document type service if needed.

          So, in that case, it's strange that there is no use of the getter. The object setter is used. The only reason the document type is on this object seems to be to allow the ID to be set.

          Show
          jkeller Jonathan Keller added a comment - The main workflow Process object also has this. It's currently using an anonymous join attribute - with no data element for the document type ID in the object. Changing this would require a change to the BO, to bring in the document type ID as a concrete attribute, so that it could be looked up from the document type service if needed. So, in that case, it's strange that there is no use of the getter. The object setter is used. The only reason the document type is on this object seems to be to allow the ID to be set.
          Hide
          jkeller Jonathan Keller added a comment -

          Just adding my notes I had since I'm not getting to this one right now:

          Document header table was queried over 100 times!

          Why was KREW_DOC_TYP_ATTR_T queried so many times? (30) That data won't change unless XML is re-ingested.
          Same with: KREW_DOC_TYP_PLCY_RELN_T.
          KREW_DOC_TYP_T
          KREW_DOC_TYP_PROC_T

          OJB relationships which are not proxied seem to be part of the problem.

          Show
          jkeller Jonathan Keller added a comment - Just adding my notes I had since I'm not getting to this one right now: Document header table was queried over 100 times! Why was KREW_DOC_TYP_ATTR_T queried so many times? (30) That data won't change unless XML is re-ingested. Same with: KREW_DOC_TYP_PLCY_RELN_T. KREW_DOC_TYP_T KREW_DOC_TYP_PROC_T OJB relationships which are not proxied seem to be part of the problem.

            People

            • Assignee:
              Unassigned
              Reporter:
              jkeller Jonathan Keller
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: