in reply to Re^2: data historization with DBIx::Class
in thread data historization with DBIx::Class

Of course the OP's request is also very naive, as (s)he assumes that all changes will be atomic on a single record.
I am not sure I understand your point...

To clarify:

What I want is a way to save an object (representing a row) BEFORE I call any updating methods on it into another table (adding a few extra attibutes e.g user-information).

This will be done in the same transaction that will eventually commit the updates to the original row.

After that I have a "before-image" (the row at transaction start) and an "after-image" (the row after commit) in the database.

Which of my assumption here is naive?

  • Comment on Re^3: data historization with DBIx::Class

Replies are listed 'Best First'.
Re^4: data historization with DBIx::Class
by CountZero (Bishop) on Dec 27, 2010 at 09:17 UTC
    There may be other connections working on the same row, updating or deleting it. Of course the transaction manager of the database will take care (or so we hope) that the database remains in a consistent state, but it may be difficult, or even impossible, to maintain a table of historical data in such a way that you can always reconstruct the status of the database at any given moment. It is surely for good reason that these internal transaction managers work on a journalling basis too!

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      It depends on the isolation level.

      As long as it's higher than "read uncommitted" (which is not really an isolation level and if that's all a data-engine can do it should not be called a database) then there should not be a problem as far as I can see.