Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: Development, JPA, Roadmap
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-9066Implement JPA version of MetadataProvider
      KULRICE-9067Implement Custom Annotation version of MetadataProvider
      KULRICE-8923Implement OJB version of PersistenceProvider
      KULRICE-2476Implement JPA versions of OJB DAOs (Data Access Objects)
      KULRICE-9108Implement support for loading of both OJB and JPA versions of KRAD client-side mappings
      KULRICE-9554Implement Metadata provider for Hibernate metadata
      KULRICE-2047Examine need for OJB specific code in PersistenceStructureServiceOjbImpl to have a similar implementation in the JPA impl
      KULRICE-9559Remove OJB implementations of provider classes
      KULRICE-6445KrmsTypeAttribute needs to be versioned.
      KULRICE-9071Implement JPA version of PersistenceProvider
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Data Dictionary, Persistence Framework
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      Create an OJB implementation of MetadataProvider for the KRAD data layer.

      I'm thinking that org.kuali.rice.krad.data.provider.ojb makes sense as the base package for this?

        Issue Links

          Activity

          Hide
          Jonathan Keller added a comment -

          So, the way this is turning out seems to be a subset of the data in the data dictionary. Either the data dictionary will need to wrap these objects or (most likely) extract the data and store in their data structures.

          Also - since these are services, should I ensure that the return value object are immutable? (That is, use the Builder pattern used elsewhere?) And, if so, does that mean that I should also be constructing these objects using groovy? (Which I don't have a problem with. Just in looking at an example in KIM, I don't see where groovy helped except for not having to define the getters and setters, which Eclipse/IntelliJ will do for us anyway.)

          Show
          Jonathan Keller added a comment - So, the way this is turning out seems to be a subset of the data in the data dictionary. Either the data dictionary will need to wrap these objects or (most likely) extract the data and store in their data structures. Also - since these are services, should I ensure that the return value object are immutable? (That is, use the Builder pattern used elsewhere?) And, if so, does that mean that I should also be constructing these objects using groovy? (Which I don't have a problem with. Just in looking at an example in KIM, I don't see where groovy helped except for not having to define the getters and setters, which Eclipse/IntelliJ will do for us anyway.)
          Hide
          Eric Westfall added a comment -

          Definitely not required to do this in groovy. We have been discussing rolling back the use of groovy for BO's anyway because it didn't really end up buying much and caused more trouble then it was worth.

          In terms of the whether or not to make these immutable. That would actually be nice from the perspective of the data dictionary being something which is consumed all over the place in the framework. However, since these can be configured as spring beans as well, I think it will be best to make them simple pojo's. If we wanted to make these data dictionary metadata objects immutable after the initial load, we could always implement a "freeze" method or equivalent which would freeze the state of the data dictionary object, but I don't think that's something which is required at least initially.

          Show
          Eric Westfall added a comment - Definitely not required to do this in groovy. We have been discussing rolling back the use of groovy for BO's anyway because it didn't really end up buying much and caused more trouble then it was worth. In terms of the whether or not to make these immutable. That would actually be nice from the perspective of the data dictionary being something which is consumed all over the place in the framework. However, since these can be configured as spring beans as well, I think it will be best to make them simple pojo's. If we wanted to make these data dictionary metadata objects immutable after the initial load, we could always implement a "freeze" method or equivalent which would freeze the state of the data dictionary object, but I don't think that's something which is required at least initially.
          Hide
          Jonathan Keller added a comment -

          I'm done with this one for now.

          Show
          Jonathan Keller added a comment - I'm done with this one for now.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel