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

Analyze usage of SequenceAccessorService and determine if we can refactor away the need to "prefetch" sequence identifier values

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: Analysis, JPA, Roadmap
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Persistence Framework
    • Sprint:
      JPA Sprint 4
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      It looks like this is mostly being done in KIM and KRMS at the moment. Can we refactor this code so that it doesn't prefetch this value but rather just allows the identifier to be assigned when the object is persisted/saved.

      If so, that would allow us to eliminate the dependency on the sequence accessor service for apps using the new data layer and we could deprecate SequenceAccessorService.

      If we were ultimately able to do this, that would also open the door in the future to taking advantage of things like auto incrementing identify columns instead of having to "fake" sequences in MySQL like we do now. I would really like to avoid adding a "getNextId" onto the PersistenceProviderInterface because that is something that a majority of implementers will not be able to implement easily or cleanly. So eliminating this requirement makes our lives a lot easier

        Attachments

          Activity

          No work has yet been logged on this issue.

            People

            • Assignee:
              ewestfal Eric Westfall
              Reporter:
              ewestfal Eric Westfall
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 days
                2d
                Remaining:
                Remaining Estimate - 1 day
                1d
                Logged:
                Time Spent - Not Specified Time Not Required
                Not Specified