Re: [gnome-db] Feature requests : reverse engeneering & md5 stamps
- From: Vivien Malerba <malerba gnome-db org>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: jm poure freesurf fr, gnome-db-list gnome org
- Subject: Re: [gnome-db] Feature requests : reverse engeneering & md5 stamps
- Date: Mon, 16 Dec 2002 16:46:35 +0100
On Mon, Dec 16, 2002 at 03:25:04PM +0100, Rodrigo Moya wrote:
> On Mon, 2002-12-16 at 09:42, Vivien Malerba wrote:
> > On Sun, Dec 15, 2002 at 03:45:17PM +0100, Jean-Michel POURE wrote:
> > > > we already have this for almost all schemas. You get the SQL for tables,
> > > > procedures, etc
> > >
> > > Sorry, I did not know.
> > >
> > > > but do you mean actually adding a field to the table (or create a new
> > > > table)? If so, I don't like the idea. libgda should be as little
> > > > intrusive as possible, and creating fields in the database (as pgaccess
> > > > does, and probably pgAdmin) is not a good idea, IMO.
> > >
> > > A function returning the md5 stamp of the SQL needed to create the object. No
> > > table should be needed.
> > >
> >
> > How about using an asynchronous notification system? The idea is that an
> > application can register to receive event notification for example when
> > a new table is created, or when a table is altered, etc. We could add
> > some signals to the GdaConnexion object for this purpose (the difficult
> > part is to see how to have a generic API non dependant on one DBMS, and
> > which signals to emit). I know that the postgres C library supports this
> > (I'm not sure about Oracle or MySQL).
> >
> > This would allow applications to always be kept up to date with database
> > structures.
> >
> heh, I already thought about this :-) :
>
> struct _GdaClientClass {
> GObjectClass parent_class;
>
> /* signals */
> void (* error) (GdaClient *client, GdaConnection *cnc, GList
> *error_list);
> //void (* action_notified) (GdaClient *client,
> // GdaActionId action,
> // GdaParameterList *params);
> };
>
> it's commented out, but it's supposed to be a signal for the GdaClient
> class to get notifications from providers, about anything (command
> executed, table modified, etc).
>
> I guess we can also put it on the GdaConnection class, and have
> GdaClient just proxy the signals from the GdaConnection's, as it already
> does for the "error" signal.
>
> If you want, I'll uncomment that piece of code, and add the same signal
> to GdaConnection, and then we can just add a
> gda_server_provider_notify_action function, which will be called by
> providers when they want to notify about an event.
>
I don't mind if the signal comes from the GdaClient (it seems better
since there is already some code for it). The question I have is how to
define all the possible events and the associated parameters. Do you
have a particular idea for the definition of the GdaActionId enum?
Cheers,
Vivien
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]