Re: [gnome-db] Feature requests : reverse engeneering & md5 stamps



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]