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

Determine how best to handle linking to DocumentHeader using JPA as was done with OJB

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: Analysis, JPA, Roadmap
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-3947Determine how to handle collections in JPA for existing applications
      KULRICE-10937Determine the best way to handle "refresh reference" and leverage EntityManager.getReference for JPA
      KULRICE-11664DocumentBase JPA versus OJB change regarding saving/restoring documentHeader
      KULRICE-9525Document best-practices for using JPA with Kuali Rice
      KULRICE-9112Determine how to handle SequenceAccessor and underlying code with JPA implementation
      KULRICE-3890Determine how best to handle persistence, attached/detached, and lazy loading for the BusinessObjectService in the context of KNS
      KULRICE-2476Implement JPA versions of OJB DAOs (Data Access Objects)
      KULRICE-6014JPA Conversion Guide
      KULRICE-10128Document how to convert OJB FieldConversion to JPA Converters, document standard converters
      KULRICE-4275Determine how best to position and package the cornell pdf enhancement
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Document, Persistence Framework
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      In the KNS/OJB, applications would simply directly reference document header as follows:

      <class-descriptor class="my.package.MyAwesomeDocument" table="awesome_doc_t">
        <field-descriptor name="documentNumber" column="doc_hdr_id" jdbc-type="VARCHAR" primarykey="true"/>
        <field-descriptor name="versionNumber" column="ver_nbr" jdbc-type="BIGINT" locking="true"/>
        <field-descriptor name="objectId" column="obj_id" jdbc-type="VARCHAR"/>
        <reference-descriptor name="documentHeader" class-ref="org.kuali.rice.krad.bo.DocumentHeader"
                              auto-retrieve="true" auto-update="object" auto-delete="object" proxy="true">
          <foreignkey field-ref="documentNumber"/>
        </reference-descriptor>
      </class-descriptor>
      

      I might be the only one who feels this way, but this seems awfully lame to me. Most glaring here is the fact that this means that the client application is required to use the same persistence technology in order to save their document-specific data. It seems like it would be better if the document itself had a transient reference to the document header and save of the document header was manually cascaded to the document header.

      It's worth mentioning that another approach is to load the DocumentHeader mapping into the client application's persistence context if they are using JPA. This can be done manually in persistence.xml or there are ways to do it programatically (I believe that Aaron H has already gotten this working).

        Activity

        Hide
        Eric Westfall added a comment -

        Also, the ability to define a custom document header override also needs to be considered here as this is what KFS is doing currently, though I honestly can't remember why.

        Show
        Eric Westfall added a comment - Also, the ability to define a custom document header override also needs to be considered here as this is what KFS is doing currently, though I honestly can't remember why.
        Hide
        Jonathan Keller added a comment -

        One possibility would be to make KFS remove the inheritance from the KRAD document header. As part of the Rice 2.0 upgrade work, I created a separate getter for anything which used the FinancialSystemDocumentHeader class. (We had overridden the getDocumentHeader() method to return a different type, and KRAD didn't like that.) It's a separate table anyway. There is probably no reason that it needs to be a subclass.

        Show
        Jonathan Keller added a comment - One possibility would be to make KFS remove the inheritance from the KRAD document header. As part of the Rice 2.0 upgrade work, I created a separate getter for anything which used the FinancialSystemDocumentHeader class. (We had overridden the getDocumentHeader() method to return a different type, and KRAD didn't like that.) It's a separate table anyway. There is probably no reason that it needs to be a subclass.
        Hide
        Eric Westfall added a comment -

        For this, we are thinking the following:

        1. DocumentHeader and related entities will be loaded into their own Persistence Context
          • This is different from how it's happening currently with OJB since there is technically only one context in OJB.
        2. There will need to be code on the Document class to "cascade" the save down to the DocumentHeader in the case that the document is using the new (non-legacy) framework.
          • This should be done using @PostPersist
          • Need to make sure there are no RI contraints that would prevent this (i.e. make sure there's no ordering issue)
        3. DocumentHeader then should be @Transient on the Document class.
        4. The "getter" for DocumentHeader on Document will need to do a lazy fetch
        5. For KFS, where they have their "FinancialSystemDocumetHeader", they will keep this, but it won't extend from DocumentHeader any longer
          • Instead they will add it to their base document class, and also @PostPersist it as well as doing lazy loading when needed (it should be @Transient as well since the save won't cascade automatically.
        • KRNS_MAINT_DOC_T
        Show
        Eric Westfall added a comment - For this, we are thinking the following: DocumentHeader and related entities will be loaded into their own Persistence Context This is different from how it's happening currently with OJB since there is technically only one context in OJB. There will need to be code on the Document class to "cascade" the save down to the DocumentHeader in the case that the document is using the new (non-legacy) framework. This should be done using @PostPersist Need to make sure there are no RI contraints that would prevent this (i.e. make sure there's no ordering issue) DocumentHeader then should be @Transient on the Document class. The "getter" for DocumentHeader on Document will need to do a lazy fetch For KFS, where they have their "FinancialSystemDocumetHeader", they will keep this, but it won't extend from DocumentHeader any longer Instead they will add it to their base document class, and also @PostPersist it as well as doing lazy loading when needed (it should be @Transient as well since the save won't cascade automatically. KRNS_MAINT_DOC_T
        Hide
        Aaron Hamid (Inactive) added a comment -

        This sounds essentially like support for cross-PU/PersistenceProvider linking which was one of the envisioned goals (i.e. ProviderCascade). So it would be cool if this could be implemented in a generic fashion and used down the road for the other types of persistence providers (nosql, webservice, etc.).

        Show
        Aaron Hamid (Inactive) added a comment - This sounds essentially like support for cross-PU/PersistenceProvider linking which was one of the envisioned goals (i.e. ProviderCascade). So it would be cool if this could be implemented in a generic fashion and used down the road for the other types of persistence providers (nosql, webservice, etc.).
        Hide
        Jonathan Keller added a comment -

        The base part of this is complete. (Not much work was required.) The KNS pieces should still work if left in place, but the document header will be loaded/saved twice each time.

        Note: #4 above was not done since we will always have the document header loaded upon initial load.

        Show
        Jonathan Keller added a comment - The base part of this is complete. (Not much work was required.) The KNS pieces should still work if left in place, but the document header will be loaded/saved twice each time. Note: #4 above was not done since we will always have the document header loaded upon initial load.
        Hide
        Jonathan Keller added a comment -

        I'm resolving for now. I'm sure more will come out as we start trying to convert the sampleapp.

        Show
        Jonathan Keller added a comment - I'm resolving for now. I'm sure more will come out as we start trying to convert the sampleapp.

          People

          • Assignee:
            Jonathan Keller
            Reporter:
            Eric Westfall
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel