«

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.

Roedy Green <> wrote in message

> 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.

David Smith wrote:
>
> 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.

--
Shane