Re: Logger for libgda

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

On 27 Nov 2000, Rodrigo Moya wrote:

> 
> > > 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?

A real secure system needs to log every data modification: the logger must
not be enabled/disabled in this case. It should be always enabled... 

If we want this behaviour, we must program the logger in the
server-side. The client mustn't be able to deactivate the logger...

> 
> > > 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?

In ASPL Fact, we will do that using a special database table: the
"Log" table. 

For example: I am redefining a product for sale. I change the price, and
the name of the product... Oh! I changed the wrong product... Please,
undo... I press the undo button and...

* I look for my last action in "Log" table:

1287 davefx  localhost 23:45:45 27/11/2000 Products 45 name="foo" 

log-ID  
      username  
               host       time      date        table_modified
						       modified_entry
						              action

OK. The last thing we did was setting a new name... So we seek the entries
where the user davefx changed the 45th entry of Products table...

Here they are:

644  davefx   localhost  13:23:21  15/11/2000 Products  45  new 
645  davefx   localhost  13:23:21  15/11/2000 Products  45  name="lulu" 
646  davefx   localhost  13:23:21  15/11/2000 Products  45  price=20.0
1286 davefx   localhost  23:44:34  27/11/2000 Products  45  price=32.05


As we can see, the last name for the 45th product was "lulu". So it's
done: the undoer saves "lulu" as name for 45th product.

The 1287th entrance to the log is marked as old. So we can make redoing
this way too.


Perhaps it is not an optimal way... but it should work.


Greetings

-- 
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