Re: [holger: Re: Logger for libgda]

[David Marín Carreño <davefx bigfoot com>]

On 28 Nov 2000, Rodrigo Moya wrote:
> On 28 Nov 2000 23:09:30 +0100, David Marín Carreño wrote:
> > On 28 Nov 2000, Rodrigo Moya wrote:
> > 
> > > 
> > > so, you're going to save the changes? But this is not reliable at all.
> > > Imagine I use:
> > > 
> > > UPDATE employees SET name = 'fulano';
> > > 
> > > ok, what you save here? that employees.name was set to 'fulano'? This is
> > > ok, you've got a log of
> > > what you've done in the DB. But, how will you recover the old data?
> > 
> > Seeking the last value of name before 'fulano'.
> > 
> 
> which is in the logger, I suppose. And what if there is a change not
> logged in? I mean, the DB
> administrator could want to suppress logs for a while, and if so, your
> system will revert the
> data to the values set, say, 3 months ago? As I said, this is not
> reliable.
> 
> Of course, we can say: once you use the logger, DON'T DISABLE IT, since
> strange things could
> happen. But of course, this is a step backwards for GDA, since we'll
> have an unreliable
> and very fond of errors system

OK. You are right... Another solution: save both the old value and the new
value. This ensure a parcial integrity of undo.

Case a) Logger always activated.
================================  
We want to change an entry, what is made in transaction A. Transaction A
has ended. The logger writes into the log the old and the new value.

We can suppose that another person changed the same entry with transaction
B before the ending of transaction A.

The resulting log could be:

645 davefx localhost 13:23:21 15/11/2000 Products.45.name "old" "ValueB"
646 davefx localhost 13:23:25 15/11/2000 Products.45.name "old" "ValueA"

The logger could now detect this conflict; thus, before writing to the
log, we look if the last change to the 45th product had "old" as new
value. If not, seek the last change to 45th product, and correct the last
entry:

646 davefx localhost 13:23:25 15/11/2000 Products.45.name "ValueB" "ValueA"

This way, we ensure the log is always semantically correct.


Case B) What happen if we deactivate the logger??
=================================================

You cannot make undoing if you deactivate the logger. So we can add some
special entries to the log indicating activations and deactivations of the
logger.

Simply: you cannot undo further than the last logger activation.

C) Will the log grow bigger and bigger?
=======================================

There could be some primitives for limiting the size of the log, and for
defining the policy of deleting log entries...

Perhaps we want to log some tables during a whole year for historical
reasons, others could be saved only for three months, and other could be
logged only for undo reasons, so they could be deleted in the next logger
deactivation, or at the end of the client session...

> > 
> > Each time we change the database, we log it. Since the creation of the
> > entry, until the last modifications. All are logged. So if we want to
> > undo, we look for the last modification before the modification we want to
> > undo.
> > 
> 
> yes, but the first time you use the logger, what would you store? and,
> as said before, what if
> the logger is disabled for some time?
> 
> > > the undoing stuff is the problem. I'd implement just a logger in >
> > > 3/4 hours, but the undoing stuff... I can't see the way we'll
> > > implement it. I hope this message give you a clue. 
>
> 
> sorry, but not, I still see a big problem in the undoing stuff.
> 

Some more tips... Perhaps we are close to the final solution... :-?

-- 
David Marín Carreño <davefx bigfoot com>   mmmm
(aka DaveFX)   ICQ UIN: 34866516            ""MM    Mm
http://www.bigfoot.com/~davefx       mmmm     mMM    MM
                                   mM"""MM    MM    mMM
ASPL Fact official developer             "M   "   mM""
http://aspl-fact.sourceforge.net             mmmm  
                                           mM"""MM         
Advanced Software Production Line SL             "M