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

JPA: discover JPA cascade/fetch option mappings vs OJB(auto-xxxx/proxy), find out what conversion scripts have done and will do for it

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 2.0
    • Fix Version/s: 1.1-JPA
    • Component/s: Development, JPA
    • Labels:
      None
    • Similar issues:
      KULRICE-6014JPA Conversion Guide
      KULRICE-3795JPA - Update/Create the conversion scripts
      KULRICE-4142JPA Conversion: provide JPA implementation of org.kuali.rice.core.dao.GenericDao
      KULRICE-2473Verify that all persistable objects are properly annotated for JPA
      KULRICE-10127Create section in document for conversion from KNS+OJB to KRAD+JPA
      KULRICE-3813JPA - JPA 2.0 testing
      KULRICE-10280Add any items you've encountered to the internal JPA conversion approach document
      KULRICE-11725Finish KIM RoleDao conversion for JPA
      KULRICE-13166Investigate better option to materialize sub objects in JPA
      KULRICE-4440Find out where the environment code is called and what it's used for
    • Application Requirement:
      Rice

      Description

      From Eric:

      http://db.apache.org/ojb/docu/guides/basic-technique.html#auto-retrieve
      I'd like for someone to do an exercise to go both directions with all of this stuff and make sure the translation is implemented in the conversion scripts and documented in the guide. i.e. figure out what all of the ojb concepts should map to in JPA and then figure out if there are any JPA cascade mappings that should be set for everything (i.e. DETACH if we can get to jpa 2.0).

      So something like this:
      autoRetrieve=false - there's really no jpa equivalent, except it seems like it would make the most sense to make this a lazy fetch type, maybe make configurable in the script?
      autoUpdate=true or object - CascadeType.PERSIST, CascadeType.MERGE
      autoUpdate=none - no related cascade types
      autoUpdate=false or link - no real JPA equivalent here, should probably treat as autoupdate=none?
      autoDelete=true - CascadeType.REMOVE
      ...
      CascadeType.REFRESH - there is no OJB equivalent to this, so by default should probably always annotate for this?
      CascadeType.DETACH - there is no OJB equivalent, should probably always annotate for this?
      ..etc...

        Issue Links

          Activity

          Hide
          Ge Zhang (Inactive) added a comment - - edited

          1, FetchType translation(proxy and auto-retrieve):

          IF using proxy:
          proxy=true should be mapped to FetchType.LAZY, proxy=false should be mapped to FetchType.EAGER

          IF not using proxy:
          auto-retrieve="true" should be mapped to FetchType.EAGER, auto-retrieve="false" should be mapped to FetchType.LAZY

          The scripts handles FetchType only by proxy, mis-translate auto-retrieve="true" into CascadeType.PERSIST, and leave auto-retrieve="false" blank

          Considering proxy, the script should be changed in this way:
          if proxy = true, translate to FetchType.LAZY regardless auto-retrieve
          if proxy = false, translate to FetchType = (auto-retrieve=true? EAGER:LAZY)

          2, AUTO-UPDATE:

          auto-update="true" or "object", because the referenced objects will be stored and linked, it should be translated into "CascadeType.PERSIST and CascadeType.MERGE"( for putting the detached referenced objects back to persistence context if they need to be referenced after being "detached".)

          auto-update(none): means do nothing to the referenced objects(no update/insert, no link created), there is no cascade types mapping to, should leave as blank

          auto-update=false(link): the actions related to this option is about linking the objects(FK assignment in 1:n and 1:1 case and indirection-table update for m:n), no JPA cascade types are related, should leave as blank

          In current script true/link/object are translated into CascadeType.MERGE , all other options are blank, it is not right

          Changes of the script for this part are:

          1 ) translate auto-update=true(object) to "CascadeType.PERSIST and CascadeType.MERGE"
          2), leave translation of auto-update=false/link/none blank

          3, AUTO-DELETE

          auto-delete(true/object) should be mapped jpa CascadeType.REMOVE

          auto-delete(none): no jpa mapping found

          auto-delete=false(link): same as "none" in 1:1 and 1:n cases. In m:n case, only links are removed(entries in indirection-table are removed), no referenced objects deleted, there is no JPA action for this, so it should be considered as auto-delete="none"

          auto-delete(none): no jpa mapping found

          so the change of the scripts for auto-delete is:

          1), translate auto-delete(true/object) into CascadeType.REMOVE
          2) leave translation of auto-delete=false/link/none as blank

          Show
          Ge Zhang (Inactive) added a comment - - edited 1, FetchType translation(proxy and auto-retrieve): IF using proxy: proxy=true should be mapped to FetchType.LAZY, proxy=false should be mapped to FetchType.EAGER IF not using proxy: auto-retrieve="true" should be mapped to FetchType.EAGER, auto-retrieve="false" should be mapped to FetchType.LAZY The scripts handles FetchType only by proxy, mis-translate auto-retrieve="true" into CascadeType.PERSIST, and leave auto-retrieve="false" blank Considering proxy, the script should be changed in this way: if proxy = true, translate to FetchType.LAZY regardless auto-retrieve if proxy = false, translate to FetchType = (auto-retrieve=true? EAGER:LAZY) 2, AUTO-UPDATE: auto-update="true" or "object", because the referenced objects will be stored and linked, it should be translated into "CascadeType.PERSIST and CascadeType.MERGE"( for putting the detached referenced objects back to persistence context if they need to be referenced after being "detached".) auto-update(none): means do nothing to the referenced objects(no update/insert, no link created), there is no cascade types mapping to, should leave as blank auto-update=false(link): the actions related to this option is about linking the objects(FK assignment in 1:n and 1:1 case and indirection-table update for m:n), no JPA cascade types are related, should leave as blank In current script true/link/object are translated into CascadeType.MERGE , all other options are blank, it is not right Changes of the script for this part are: 1 ) translate auto-update=true(object) to "CascadeType.PERSIST and CascadeType.MERGE" 2), leave translation of auto-update=false/link/none blank 3, AUTO-DELETE auto-delete(true/object) should be mapped jpa CascadeType.REMOVE auto-delete(none): no jpa mapping found auto-delete=false(link): same as "none" in 1:1 and 1:n cases. In m:n case, only links are removed(entries in indirection-table are removed), no referenced objects deleted, there is no JPA action for this, so it should be considered as auto-delete="none" auto-delete(none): no jpa mapping found so the change of the scripts for auto-delete is: 1), translate auto-delete(true/object) into CascadeType.REMOVE 2) leave translation of auto-delete=false/link/none as blank
          Hide
          Ge Zhang (Inactive) added a comment -

          Annotate the CacadeTypes from JPA side has many variations, most likely it is a case by case thing, depending on your data model and the required life cycle of the associated entites. But thinking of what the conversion script should do may put some limitation on it. Here is what I got so far:

          CascadeType.REFRESH, it looks like a good mapping to auto-retrieve=true, but OJB doc pointed out that auto-retrieve is about loading referenced obj instead of refreshing the obj state from underlying database, so CascadeType.REFRESH ends up with no mapping to OJB. But, it is more reasonable to refresh referenced obj when the owing obj is refreshed, so I think this type should be annotated by default in the script, the client apps can change it if they don't want this behavior.

          CascadeType.DETACH, unlike MERGE(owing entity may need the detached referenced entities also merged back to the cache for its reference and other operations, it is one of the reasons why auto-upate="true" mapps to PERSIST and MERGE), referenced entities may still need so stay in the persistence context cache after the owing entity is detached(for example KFS may still want to deal with chartaccount when account is detached ). So the script should not annotate this by default.

          CascadeType.ALL , it makes sense to annotate this in the case that referenced entity's life span is bounded by the the owing entity, so it is a case by case decision, the script should not make it annotated by default.

          Show
          Ge Zhang (Inactive) added a comment - Annotate the CacadeTypes from JPA side has many variations, most likely it is a case by case thing, depending on your data model and the required life cycle of the associated entites. But thinking of what the conversion script should do may put some limitation on it. Here is what I got so far: CascadeType.REFRESH, it looks like a good mapping to auto-retrieve=true, but OJB doc pointed out that auto-retrieve is about loading referenced obj instead of refreshing the obj state from underlying database, so CascadeType.REFRESH ends up with no mapping to OJB. But, it is more reasonable to refresh referenced obj when the owing obj is refreshed, so I think this type should be annotated by default in the script, the client apps can change it if they don't want this behavior. CascadeType.DETACH, unlike MERGE(owing entity may need the detached referenced entities also merged back to the cache for its reference and other operations, it is one of the reasons why auto-upate="true" mapps to PERSIST and MERGE), referenced entities may still need so stay in the persistence context cache after the owing entity is detached(for example KFS may still want to deal with chartaccount when account is detached ). So the script should not annotate this by default. CascadeType.ALL , it makes sense to annotate this in the case that referenced entity's life span is bounded by the the owing entity, so it is a case by case decision, the script should not make it annotated by default.
          Hide
          Ge Zhang (Inactive) added a comment -

          After the discussion in today's dev meeting, we decide that conversion script should annotate CascadeType.DETACH by default.

          Just updated JPA conversion guide at OJB vs JPA section:
          https://test.kuali.org/confluence/display/KULRICE/JPA+Conversion+Guide

          Show
          Ge Zhang (Inactive) added a comment - After the discussion in today's dev meeting, we decide that conversion script should annotate CascadeType.DETACH by default. Just updated JPA conversion guide at OJB vs JPA section: https://test.kuali.org/confluence/display/KULRICE/JPA+Conversion+Guide

            People

            • Assignee:
              Ge Zhang (Inactive)
              Reporter:
              Ge Zhang (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel