Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0
    • Fix Version/s: 1.1-JPA
    • Component/s: Documentation
    • Labels:
      None
    • Similar issues:
      KULRICE-9361KNS to KRAD Conversion Guide
      KULRICE-10127Create section in document for conversion from KNS+OJB to KRAD+JPA
      KULRICE-9923Conversion Guide: Multi Value Lookup
      KULRICE-9924Conversion Guide: Other Lookup Features
      KULRICE-10543Verification of Inquiry Conversion Guide
      KULRICE-11561Check that Lookup conversion guide and conversion scripts are up to date
      KULRICE-11562Check that Inquiry conversion guide and conversion scripts are up to date
      KULRICE-11563Check that Maintenance conversion guide and conversion scripts are up to date
      KULRICE-3876JPA - Convert KEW to use JPA
      KULRICE-10120Attribute Definition: Conversion Guide

      Description

      • Just a general comment - this document needs to be written not only for a target audience that includes the KFS and KC projects, but also any existing Rice client applications that are out there in the wild
      • Include just a general overview of why we are making the change, what JPA is, information on the default implementation we are using
      • reference that we were hoping to use JPA 2.0 but it won't be available
      • document that we are dropping support for OJB so this is an impacting and forced upgrade
      • Have a quick introduction with some examples of how to map objects in JPA and what the different annotations are that we are likely to use
        • also need to document any custom annotations and the vendor specific ones that we are using
      • Document the difference between OJB and JPA and how they need to be handled
        • store and persist/merge difference
        • if you don't want a field to be persisted, you have to mark it @Transient
          • jpa assumes you want all fields persisted on pojo, unless they are marked
        • document how Boolean type persistence for Y/N is handled
      • Include documentation on how to use our new custom criteria api and how it differs from the OJB version
      • include documentation on how to write JPQL and translate from OJB criteria to JPQL (sort of a standard approach)
      • document any best practices that we recommend (i.e. JPQL over criteria, how to configure entity managers, etc.)
      • Document how to run the conversion script and exactly what it does
      • We should also be sure to include a step-by-step guide that someone follow to perform the conversion
      • include general instructions on how to write a DAO for JPA
      • document how to configure a Rice client application for JPA
        • in Spring, etc.
      • document the JPA feature that allows you to verify the jpa mappings vs. your database, this will probably mostly come in handy for development and verifications purposes

      This guide is a team wide task. It is expected for everyone working on the JPA conversion to add to this guide.

      The current guide location is:
      https://test.kuali.org/confluence/display/KULRICE/JPA+Conversion+Guide

      Here's a list of some of the JPA information we have so far compiled:

      Nate's guide (VERY good source on the conversion)
      https://test.kuali.org/confluence/display/KULRICE/JPA+Analysis

      KS JPA Guide (General info on using JPA):
      https://test.kuali.org/confluence/display/KULSTA/JPA

      https://test.kuali.org/confluence/display/KULRICE/Finish+JPA+Implementation+for+Rice+1.1

      https://test.kuali.org/confluence/display/KULRICE/Implementation+Details

      https://test.kuali.org/confluence/display/KULRICE/Rice+JPA+Issues

        Issue Links

          Activity

          Hide
          James Smith added a comment -

          Garey is pulling together JPA analysis here: https://test.kuali.org/confluence/display/KULRICE/JPA+Analysis

          Show
          James Smith added a comment - Garey is pulling together JPA analysis here: https://test.kuali.org/confluence/display/KULRICE/JPA+Analysis
          Hide
          James Smith added a comment -

          Just as an extension to the note "reference that we were hoping to use JPA 2.0 but it won't be available"...when there's functionality that OJB provides that JPA 1.0 does not yet provide, then Hibernate specific coding will be used, right? If so, that should be noted in the documents as well (as well as what those pieces of functionality are).

          Show
          James Smith added a comment - Just as an extension to the note "reference that we were hoping to use JPA 2.0 but it won't be available"...when there's functionality that OJB provides that JPA 1.0 does not yet provide, then Hibernate specific coding will be used, right? If so, that should be noted in the documents as well (as well as what those pieces of functionality are).
          Hide
          Garey Taylor added a comment -

          Yes, that would be something good to add to the documentation.

          As an interesting side note, JPA 2.0 ref impl has been release by eclipselink. I need to talk with Eric about this.

          Show
          Garey Taylor added a comment - Yes, that would be something good to add to the documentation. As an interesting side note, JPA 2.0 ref impl has been release by eclipselink. I need to talk with Eric about this.
          Hide
          Garey Taylor added a comment - - edited

          I added some raw configuration comments to :

          https://test.kuali.org/jira/browse/KULRICE-2478

          Show
          Garey Taylor added a comment - - edited I added some raw configuration comments to : https://test.kuali.org/jira/browse/KULRICE-2478
          Hide
          James Smith added a comment -

          Yeah, actually - JPA 2 has evidently been final for nearly a month; EclipseLink looks really up on the game (Nate spoke well of it too on that page I linked to above).

          Show
          James Smith added a comment - Yeah, actually - JPA 2 has evidently been final for nearly a month; EclipseLink looks really up on the game (Nate spoke well of it too on that page I linked to above).
          Hide
          Eric Westfall added a comment -

          We'll want to seriously consider JPA 2.0 if it's really ready for primetime. However, I think we can still start out with JPA 1.0 as we've done so far. We'll need to figure out what the implications might be of a move to JPA 2.0 and what that would mean.

          Show
          Eric Westfall added a comment - We'll want to seriously consider JPA 2.0 if it's really ready for primetime. However, I think we can still start out with JPA 1.0 as we've done so far. We'll need to figure out what the implications might be of a move to JPA 2.0 and what that would mean.
          Hide
          James Smith added a comment -

          This link is just here for my future reference:

          http://www.ibm.com/developerworks/java/library/j-typesafejpa/index.html

          I still didn't see much type conversions in the JPA 2 spec (though I was mostly skimming the TOC). Anyway...outlining and writing...

          Show
          James Smith added a comment - This link is just here for my future reference: http://www.ibm.com/developerworks/java/library/j-typesafejpa/index.html I still didn't see much type conversions in the JPA 2 spec (though I was mostly skimming the TOC). Anyway...outlining and writing...
          Hide
          Garey Taylor added a comment -

          I got the jpa version of the ksb working yesterday. I committed my code to the 1.1.0 branch.
          In order to enable jpa for ksb, please paste the following into your config file:

          <!-- JPA Oracle Config -->
          <param name="rice.ksb.jpa.enabled">true</param>
          <param name="rice.jpa.JpaProperties.hibernate.hbm2ddl.auto">validate</param>
          <param name="rice.jpa.DatabasePlatform">org.hibernate.dialect.OracleDialect</param>
          <param name="rice.jpa.UseSerialization">false</param>

          <!-- JPA Config for KSB -->
          <param name="rice.ksb.registry.jpa.PersistenceXmlLocation">META-INF/ksb-persistence.xml</param>
          <param name="rice.ksb.registry.jpa.PersistenceUnitName">ksb-sequence-registry-unit</param>
          <param name="rice.ksb.registry.jpa.GenerateDdl">true</param> <!-- Optional -->

          <param name="rice.ksb.message.jpa.PersistenceXmlLocation">META-INF/ksb-persistence.xml</param>
          <param name="rice.ksb.message.jpa.PersistenceUnitName">ksb-sequence-message-unit</param>
          <param name="rice.ksb.message.jpa.GenerateDdl">true</param> <!-- Optional -->
          <!-- End JPA Oracle Config -->

          Note, this is only for Oracle. If you want to use mySql you need to change the dialect and the unit names. The unit names would be "ksb-identity-registry-unit" and "ksb-identity-message-unit". The reason we have these two settings is because mysql and oracle handle sequences differently.

          We have a way to handle these in the code, but for some reason it wasn't working for me. Oh well. Use this for now.

          Show
          Garey Taylor added a comment - I got the jpa version of the ksb working yesterday. I committed my code to the 1.1.0 branch. In order to enable jpa for ksb, please paste the following into your config file: <!-- JPA Oracle Config --> <param name="rice.ksb.jpa.enabled">true</param> <param name="rice.jpa.JpaProperties.hibernate.hbm2ddl.auto">validate</param> <param name="rice.jpa.DatabasePlatform">org.hibernate.dialect.OracleDialect</param> <param name="rice.jpa.UseSerialization">false</param> <!-- JPA Config for KSB --> <param name="rice.ksb.registry.jpa.PersistenceXmlLocation">META-INF/ksb-persistence.xml</param> <param name="rice.ksb.registry.jpa.PersistenceUnitName">ksb-sequence-registry-unit</param> <param name="rice.ksb.registry.jpa.GenerateDdl">true</param> <!-- Optional --> <param name="rice.ksb.message.jpa.PersistenceXmlLocation">META-INF/ksb-persistence.xml</param> <param name="rice.ksb.message.jpa.PersistenceUnitName">ksb-sequence-message-unit</param> <param name="rice.ksb.message.jpa.GenerateDdl">true</param> <!-- Optional --> <!-- End JPA Oracle Config --> Note, this is only for Oracle . If you want to use mySql you need to change the dialect and the unit names. The unit names would be "ksb-identity-registry-unit" and "ksb-identity-message-unit". The reason we have these two settings is because mysql and oracle handle sequences differently. We have a way to handle these in the code, but for some reason it wasn't working for me. Oh well. Use this for now.
          Hide
          James Smith added a comment -

          I'm already fairly confident that I'll need to farm out the JPA configuration section to someone else. Garey, suggestions of a victim-er-expert?

          Show
          James Smith added a comment - I'm already fairly confident that I'll need to farm out the JPA configuration section to someone else. Garey, suggestions of a victim- er -expert?
          Hide
          Garey Taylor added a comment -

          I'm still no expert on the current JPA config, but look at this JIRA for some config options:

          https://test.kuali.org/jira/browse/KULRICE-2478

          Show
          Garey Taylor added a comment - I'm still no expert on the current JPA config, but look at this JIRA for some config options: https://test.kuali.org/jira/browse/KULRICE-2478
          Hide
          James Smith added a comment -

          Thanks Garey, I'm taking a close look.

          Show
          James Smith added a comment - Thanks Garey, I'm taking a close look.
          Hide
          James Smith added a comment -

          Another James random note: SequenceAccessorDaoJdbc is pretty much actually an OJB DAO.

          Show
          James Smith added a comment - Another James random note: SequenceAccessorDaoJdbc is pretty much actually an OJB DAO.
          Hide
          James Smith added a comment -

          Oh, never mind - Nate added JPA stuff to that. The OJB just has to be stripped out. Sorry!

          Show
          James Smith added a comment - Oh, never mind - Nate added JPA stuff to that. The OJB just has to be stripped out. Sorry!
          Hide
          James Smith added a comment -

          Interesting thread on the merge/persist thing: http://forums.java.net/jive/thread.jspa?threadID=28896

          Show
          James Smith added a comment - Interesting thread on the merge/persist thing: http://forums.java.net/jive/thread.jspa?threadID=28896
          Hide
          James Smith added a comment -

          So I read this: http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html_single/#objectstate

          which got into transitive persistence...which I find confusing. It sounds like as long as there's a set type on something, then merges also merge all child objects; but if there's a collection where the type is lost, then children have to be merged one by one?

          Anyway: this made me think about OJB's maintained collection which I thought automatically persisted removals from collections. I'm curious if that's part of this transitive persistence thing.

          Show
          James Smith added a comment - So I read this: http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html_single/#objectstate which got into transitive persistence...which I find confusing. It sounds like as long as there's a set type on something, then merges also merge all child objects; but if there's a collection where the type is lost, then children have to be merged one by one? Anyway: this made me think about OJB's maintained collection which I thought automatically persisted removals from collections. I'm curious if that's part of this transitive persistence thing.
          Hide
          James Smith added a comment -

          Note to self: we do need the orm.xml persistence file because overridden classes can't have existing attributes changed without shadowing - which is ugly (the classic case: BO extensions). So let's get that back into the documentation.

          Show
          James Smith added a comment - Note to self: we do need the orm.xml persistence file because overridden classes can't have existing attributes changed without shadowing - which is ugly (the classic case: BO extensions). So let's get that back into the documentation.
          Hide
          James Smith added a comment -

          A list of what I have left to finish, which mostly depend on outstanding questions:

          • a list of where vendor-specific extensions were used
          • does JPA 2's meta model actually offer the ability to do metadata lookup without a vendor-specific extension? JPA 2's meta model is weird and I honestly don't know how they've done it (I'm dying to find out though), if you can reflect off it, etc.; I'd have to write a small sample project to try it out
          • I couldn't find Nate's Boolean to Char user type in the project...
          • do we need to include KS's Atomikos configuration stuff in the document?
          • Does Rice have an official stance on which inheritance mechanism should be used?
          • The line "If an entity will be queried with a name different than the class name, additional properties can be provided" - I'm not quite sure what that means in terms of MappedSuperclasses - I'll read the spec
          • I'm philosophically opposed to many-to-many ORM mappings. Do I have to include them in the JPA Conversion document? ; - >
          • take out line in BusinessObjectExtension about whether we should now be using JPA inheritance for this
          • table of contents (once Dan and Ge finish); anywhere where OJB vs JPA is discussed should be in an {info} box
          Show
          James Smith added a comment - A list of what I have left to finish, which mostly depend on outstanding questions: a list of where vendor-specific extensions were used does JPA 2's meta model actually offer the ability to do metadata lookup without a vendor-specific extension? JPA 2's meta model is weird and I honestly don't know how they've done it (I'm dying to find out though), if you can reflect off it, etc.; I'd have to write a small sample project to try it out I couldn't find Nate's Boolean to Char user type in the project... do we need to include KS's Atomikos configuration stuff in the document? Does Rice have an official stance on which inheritance mechanism should be used? The line "If an entity will be queried with a name different than the class name, additional properties can be provided" - I'm not quite sure what that means in terms of MappedSuperclasses - I'll read the spec I'm philosophically opposed to many-to-many ORM mappings. Do I have to include them in the JPA Conversion document? ; - > take out line in BusinessObjectExtension about whether we should now be using JPA inheritance for this table of contents (once Dan and Ge finish); anywhere where OJB vs JPA is discussed should be in an {info} box
          Hide
          James Smith added a comment -

          Also if Chad could take a look at the merge/persist stuff, that would be great.

          Show
          James Smith added a comment - Also if Chad could take a look at the merge/persist stuff, that would be great.
          Hide
          James Smith added a comment -

          Notes from conversation with Garey:

          • let's leave the JPA 2 meta model stuff out for now until we can experiment (for conversion purposes, that's all hidden behind PersistentStructureService or whatever it is anyway)
          • Garey would look into the boolean conversion
          • leave out the Atomikos conversion stuff for now
          • There is no Rice official stance on inheritance mechanism. I noted in our conversation that KNS + KFS uses both: accounting lines are single table inheritance, business object extensions are kind of multiple table composition. Personally, I like mutliple table composition, but the single table inheritance in KFS completely makes sense for that use case.
          • Garey is also philosophically opposed to many-to-many relationships. n:n - you've been denied!! (er, for now)

          I'll get this wrapped up tomorrow.

          Show
          James Smith added a comment - Notes from conversation with Garey: let's leave the JPA 2 meta model stuff out for now until we can experiment (for conversion purposes, that's all hidden behind PersistentStructureService or whatever it is anyway) Garey would look into the boolean conversion leave out the Atomikos conversion stuff for now There is no Rice official stance on inheritance mechanism. I noted in our conversation that KNS + KFS uses both: accounting lines are single table inheritance, business object extensions are kind of multiple table composition. Personally, I like mutliple table composition, but the single table inheritance in KFS completely makes sense for that use case. Garey is also philosophically opposed to many-to-many relationships. n:n - you've been denied!! (er, for now) I'll get this wrapped up tomorrow.
          Hide
          James Smith added a comment -

          This is cleaned up now (and both removed the notes addressed to me and added the TOC, hooray!) I'll probably give it a quick read later in the day to see if I notice any egregious editorial errors. When that's complete, Garey, who should I hand the documentation off to next?

          Show
          James Smith added a comment - This is cleaned up now (and both removed the notes addressed to me and added the TOC, hooray!) I'll probably give it a quick read later in the day to see if I notice any egregious editorial errors. When that's complete, Garey, who should I hand the documentation off to next?
          Hide
          James Smith added a comment -

          Okay, having reread, there's two more issues I think the doc should address, which I can write up later next week (so: no reason for this document not to go to the next person for editing...)

          1) Will we need some standard for naming composite keys (the example in the document uses

          {class name}

          +Id) so that BusinessObjectService#getByPrimaryKey can always successfully turn a Map into a PK object or is there some metadata way to do that? If a standard is required, is there some coding way we could break compilation if it isn't? Maybe we need to specify the PK class in the data dictionary?

          2) In one of the documents, Eric brought of the issue of: you're rendering a business object which has a proxied collection as a one-to-many relationship - is there a danger that the DB connection will be lost by the proxy before the rendering completes? If so, what's the strategy to deal with that? ...it probably should be documented.

          Show
          James Smith added a comment - Okay, having reread, there's two more issues I think the doc should address, which I can write up later next week (so: no reason for this document not to go to the next person for editing...) 1) Will we need some standard for naming composite keys (the example in the document uses {class name} +Id) so that BusinessObjectService#getByPrimaryKey can always successfully turn a Map into a PK object or is there some metadata way to do that? If a standard is required, is there some coding way we could break compilation if it isn't? Maybe we need to specify the PK class in the data dictionary? 2) In one of the documents, Eric brought of the issue of: you're rendering a business object which has a proxied collection as a one-to-many relationship - is there a danger that the DB connection will be lost by the proxy before the rendering completes? If so, what's the strategy to deal with that? ...it probably should be documented.
          Hide
          James Smith added a comment -

          Other than those two things, and the fact that my documentation still feels "pagey" to me - something I need to work on - should I turn this over to someone else?

          Show
          James Smith added a comment - Other than those two things, and the fact that my documentation still feels "pagey" to me - something I need to work on - should I turn this over to someone else?
          Hide
          James Smith added a comment -

          Added the Type Conversions section and the fact that we have to use Hibernate's type conversion stuff (it's not even in JPA 2, evidently).

          Also, remembered the non-boolean place we use type conversions in KFS: encrypted data is performed through a type conversion.

          Show
          James Smith added a comment - Added the Type Conversions section and the fact that we have to use Hibernate's type conversion stuff (it's not even in JPA 2, evidently). Also, remembered the non-boolean place we use type conversions in KFS: encrypted data is performed through a type conversion.
          Hide
          Jessica Coltrin (Inactive) added a comment -

          Since JPA conversion is not in the near future, closing this for now and we can create another once we're working there.

          Show
          Jessica Coltrin (Inactive) added a comment - Since JPA conversion is not in the near future, closing this for now and we can create another once we're working there.

            People

            • Assignee:
              Unassigned
              Reporter:
              Garey Taylor
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel