Re: [holger: Re: Logger for libgda]

[Holger Thon <holger gidayu mud de>]

Hi!

On Tue, Nov 28, 2000 at 08:55:22PM -0100, Rodrigo Moya wrote:
> 
> > > 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.
> > 
> > And the log must be written only when the transaction has already 
> > finished.
> > 
> 
> 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?
> 
> This would be easy if you always used expressions such as:
> 
> UPDATE employees SET salary = salary + 200;
> 
> here, it's easy, you can recover by just doing
> 
> UPDATE employees SET salary = salary - 200;
> 
> But with other kind of expressions, I don't see the way you're going to
> recover the old data
> when undoing.
I think david wants to parse the sql statement before its actually commited
on the server, thus having the possibility to check for old values before
the transaction is made. On transaction based syytems, this is the easiest
solution, i suppose. For simple sql queries, one would do the same: Look
for the old data before the query is sent to the server and gets executed.

However you are right, that a generic change of a complete column will be
a bit harder to evaluate then that of a specific cell/row. On large tables,
such an update clause will significantly reduce the clients performance,
because without logging/evaluating it would be executed on the performant
server. When getting the complete column from the server for such a query,
the client would have a lot of work more, though.
> 
> > > > 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 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.

Having just a single client it wouldn't be that hard, but libgda is made
for also working in networks, so using multiple clients isn't that inobvious.
On a single client, you could predict that undo would only work if libgda
is used for each transaction, and the logger is happy. With more clients,
you have to move the complex synchronization process also running on the
server to each client for achieving a save undo function. I don't think
it's unsolvable, though.

Ciao,

  Holger