Keeping old versions of data for audit trails and save/discard feature

D

David Smith

Hello,

I have some objects (EJBs) that I would like to keep old versions of.
This is both for reasons of keeping an audit trail and also to
implement a save/discard feature, whereby users can make changes to
the objects and then decide whether they want to keep these changes or
discard them (and roll back to an older version) when they have
finished manipulating all the objects.

The objects are entity beans being persisted to a relational database.

Does anyone have any thoughts on the best way to store this version
information? I am defining "best" here as being the most generic and
least obtrusive technique. Perhaps there is an API somewhere that can
handle this, because it seems to be quite a common problem, but I
haven't been able to find anything suitable.

Thanks,
David.
 
D

David Smith

Roedy Green said:
Usually the pod deals with that does it not? It will rollback objects
if you don't commit the transaction. In that case, you should not
mark the objects specially in any way.

Yes, the database would handle transactions, but for this particular
project the time-frame is too long. The following scenario could
occur:

Person A creates some objects and saves them as a permanent change.
That's version 1.

Person B does some modifications the next day, but doesn't yet save or
discard them, they're a work in progress. However, they have to be
kept in the database so that they can be worked on in the future, by
both Person B and other people.

Person A comes back into the system a few days later and then decides
to make some more changes. Now he's happy with all the objects, so he
saves them as the second permanent change.


I don't think that normal database transactions can be used here, can
they, because the intermediate states that a normal transaction would
just roll back have to be saved to the database?

Kind regards,
David.
 
S

Shane Petroff

David said:
I have some objects (EJBs) that I would like to keep old versions of.

I copped out and simply use a database trigger to handle this. It just
dumps out the whole record into a logging table which my app doesn't
know about. I also prepend an operation_type field ("insert", "delete",
"update from", "update to") and a timestamp so that the poor slob who
has to report on this table knows what was happening at the time.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top