Re: Logger for libgda



> > 
> > * LogEntry-ID
> > * User (who access the database)
> > * Date
> > * Time
> > * Host (from where the database is accessed)
> > * Table (changed)
> > * Entry (changed)
> > * Changes (new values of the fields, or something so).
> 
> The main problem here is, that you need to generate a query issuing the
> "undo" sql statement to the server. For this, you need to know the sql
> dialect a server understands. I doubt, that this would be possible on
> all providers (e.g. the mail provider lacks sql), however i think this
> is a great idea. Possibly, it might work with the xml-query/reporting
> feature of libgda/gnome-db in future, if the server has also implemented
> this feature.
> 
yes, this is one problem I hadn't thought before. How would you build the
SQL (or whatever) command to make the undo? To do so, you'll be more or less
simulating a transaction, as you'll have to store the data before executing
the command.

So, as I said before, I think the best solution for this is to simulate
transactions in the providers that don't support them

> 
> > Now, we are implementing this stuff in the client-side. But we want to
> > program it in the server-side. And the problem is here: we want to
> > continue using libgda for accessing the database. Thus, the logger should
> > be transparent for gda...
> 
> I don't think that enhancing the server code much would be a good solution.
> I'm not that fit in bonobo-api, but i think the attempt should be started
> on top of gda-server api, adding plugin possibilities. 
> Then, a plugin can directly call the gda-provider with plugin functions using
> its oaf id. 
> 
> Depending on the server, a different sql dialect could be selected. A generic
> SQL9x conform driver should be added as well, as most databases understand it.
> Another possibility would be to add such a plugin for each server, but it
> would be much more overhead in my opinion.
> 
> > So we thought... why don't insert the logger into gda? We think that a
> > logger module would be very useful for every program with database access.
> 
> This is of course a great idea, but i think it should be separated into a
> plugin so that components remain modular and flexible.
> 
or in the client side. This will mean storing per-user logs, or if we
really want it, in a central area (through GConf).

cheers





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]