Re: Logger for libgda

[Rodrigo Moya <rodrigo gnome-db org>]

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

yes, here you're right. Critical apps would prefer to log everything.
So, to avoid bad client
apps making what they want, we could have this log on/off flag set up by
provider, and
totally hidden to clients.

> > 
> > > > 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.
> 
well, it's not a bad idea, but I see some problems:

* the entries you're showing are (as I understand it) saving the old
values for the affected rows. So,
  again, how do you know which rows are going to be affected? you save
all the table(s)
  contents? you parse the SQL command? or is the client (which should
know what rows, or
  at least which tables/fields, are going to be modified) who makes that
save action?
* with either solution to the above problem, I see some issues about
speed and
  performance related to the way of knowing which rows are affected, and
how to save all the
  data going to be modified. Of course, for some applications this might
not be an issue at all.

as soon as we find a solution for this, I think we can go ahead and
implement it in GDA. What
other people think?

cheers