1 Reply Latest reply on Jul 17, 2011 1:57 AM by Adam Warski

    Alternate/New Revision Strategy

    Jeremy Higbee Newbie



      I'm still very new to the Hibernate and Envers worlds, but I'm currently working on a program that maps employees in my orginization to the job positions that they hold, and etc.  That being said, I do not have WRITE access to the "authoritative" data sources, and my application is a grass-roots type of setup where I'm trying to convinve people up the line from me that we can operate better/easier, so I don't have a lot of orginizational support at the moment.


      Given that I do not have WRITE access to the data sources, I can still read them (usually in Excel form, which I use Apache POI to read).  From there, I populate an embedded server (Derby) (until I can convince the orginization to provide a network DB) with the data from the Excel files.  At this point, and currently, I'm using Hibernate and Envers for persistence (JPA style) with auditing of revisions.  However, I don't think the audit/revision strategy works for my needs.  From my understanding, changes in entity objects immediately become the current version of the object in the main database, with previous versions going to the audit tables. 


      Is there any better strategy that I can impliment with Envers?  I think I need some way to maintain a copy of the "official records" so that I can always know what's still current in the official channels, but then I think I need to treat revisions to objects as "proposed changes".  My system would then generate the necessary paperwork for the orginization to impliment the changes in the official systems/records, and if the changes are approved, we would see the change in the next import of official data (from the Excel spreadsheets).  Is this outside the scope of Envers?  If so, does anyone have any ideas on a way ahead?


      Thanks guys!



        • 1. Re: Alternate/New Revision Strategy
          Adam Warski Master



          It looks like you could use e.g. a workflow system (jbpm?); Envers just provides you with an easy way to audit entities, that is store the historical data. It doesn't include managing current/proposed system states, which is a very simple form a workflow, and probably will evolve into a more complicated one.