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

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

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

Replies are listed 'Best First'.
Re^5: data historization with DBIx::Class
by morgon (Priest) on Dec 27, 2010 at 16:43 UTC
    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.