Re: Logger for libgda

[Rodrigo Moya <rodrigo gnome-db org>]

> > the GDA architecture right now allows to put this logger both in the client
> > and server part. Right now we've got a startLogging method in the IDLs
> > but that starts the provider's specific log stuff (that is, ODBC logs,
> > postgres libs). So, where do you want it?
> >
> 
> If you put it in the server, the database will be more secure: nobody
> could access to the database without logging (only if you can set the
> logger to be activated forever).
> 
> If you put the logger in the client-side, an evil hacker could program a
> modified client, and access the database server without logging.
> 
I don't understand what you mean here. The logging stuff should be optional,
so a client would call, for example:

gda_connection_enable_logger(Gda_Connection* cnc);

And what do you mean by accessing the database without logging?

> > What I don't understand is the undo stuff. Isn't it better to use
> > transactions? Of course, some GDA providers don't support them, but I think
> > the best thing to do about this is to implement a transaction simulation
> > for those providers.
> 
> Transactions only give one-level of undoing. With the logger, you get a
> lot of undo levels...
> 
yes, here you're right. The only way I know of solving this is to use
XA transactions, which offer several levels of transactions, but, of course,
this is only implemented in a few DB systems (Oracle that I know). Well,
and savepoints in transactions can also be a way to have this, but again, this
is (AFAIK) only implemented in some DB systems.

But I still see a problem on how to implement this. As you said, each provider
could have a method for undoing one command, but how this undo action could
be done without using things such as transactions? You could save the data
going to be affected, but how would you know which data is going to be
changed before actually executing the command?

cheers