Re: [holger: Re: Logger for libgda]

[Holger Thon <holger gidayu mud de>]

On Tue, Nov 28, 2000 at 10:45:17PM +0100, David Marín Carreño wrote:
> On 28 Nov 2000, Rodrigo Moya wrote:
> 
> > > Anyway, you have to fetch the data a transaction attempts to modify 
> > > from the server before applying that transaction, and log that data first.
> > > This would be a great hint for avoiding collision of multiple transactions
> > > from multiple systems:
> > >  Client a modifies some data and commits transaction. After that, client b
> > >  modifies the commited data (making it right again and applying some updates)
> > >  and commits his transaction. Now client a issues an undo. Updates of client
> > >  b would be lost, because they're not in the log of client a.
> > > 
> > 
> > yes, another problem that is raised now. Special care should be taken to
> > avoid this. And I ask
> > again: how could we do that?
> 
> After any change in the database, the log mustn't save the old status. It
> must save the changes. It is slower when undoing, but it hasn't this
> problem.
Sure. And the data which actually is on the server can be compared on the fly
with the new data shown by the transaction logs, before the generated undo
transaction will be commited. However, this must be an efficient algorithm
with least runtime possible to avoid the problem above.

> And the log must be written only when the transaction has already 
> finished.
Agree.

> 
> > > Hope this problems can be solved, because i think having multiple
> > > undo levels on transactions is a great idea and a valuable feature
> > > for libgda!
> >
> > I also like the idea of having the logger in GDA, but only if we find
> > a good way of handling all these problems (and others that will
> > appear). But remember that if it's going to be in GDA, it should be as
> > generic as possible, making it suitable for ANY data source supported
> > by GDA.
> 
> I cannot see any problem here... Sorry ;-)
The main problem is an efficient "parser" (needed for sql query evaluation),
which can gather information from both transaction log and sql queries quick
to form an undo query.
With xml, the parsing problem will be relativly small, so the optimization
might be tricky. Though, i agree it'd be solvable. :-)


Ciao,

  Holger