[KULRICE-9384] Analyze usage of SequenceAccessorService and determine if we can refactor away the need to "prefetch" sequence identifier values Created: 25/Apr/13 Updated: 21/Apr/14 Resolved: 12/Aug/13
|Project:||Kuali Rice Development|
|Component/s:||Analysis, JPA, Roadmap|
|Security Level:||Public (Public: Anyone can view)|
|Reporter:||Eric Westfall||Assignee:||Eric Westfall|
|Remaining Estimate:||1 day|
|Time Spent:||Not Specified|
|Original Estimate:||2 days|
|Epic Link:||Migrate KRAD to use krad-data APIs|
|KRAD Feature Area:||
|Sprint:||JPA Sprint 4|
|KAI Review Status:||Not Required|
|KTI Review Status:||Not Required|
|Include in Release Notes?:||
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
|Comment by Eric Westfall [ 30/Jul/13 ]|
Other projects are doing this as well. Even if we did factor such away, there's still no way in JPA to say "use sequences if the database supports them, use identity columns if not". So instead we implemented the @PortableSequenceGenerator which appears to be a cleaner solution here and allows us to continue with our sequence emulation layer on databases like MySQL.