[gnome-db] RE: gASQL

[Vivien MALERBA <malerba gnome-db org>]

Le mer 04/09/2002 à 14:59, Rodrigo Moya a écrit :
> > Ok, here is what I'd like to see in mergeant about schemas management
> > (by order of priority), and depending on the capabilities of the DBMS
to
> > which Mergeant is connected:
> > * being able to create new tables:
> >      - using the known data types
> >      - having default values, primary key, foreign key,
> >        not null, etc properties
> >
> this is all supported in the GdafieldAttributes structure, which is to
> be filled by providers in the describe_column method. So, we can easily
> reuse this structure to send the structure of a table to be created to
> the provider. The question is how we want to do this (see below).
>
> >      - enabling the inheritance of other tables
> >
> for this, we'd need to pass to the provider that info along with the
> GdaFieldAttributes array describing the columns. So, as I said the
> question is how to do this. The easiest thing is to add a:
>
> gboolean create_table (const gchar *name, GdaParameterList *params,
> GdaFieldAttributes *description[], gint columns)
>
> method to the provider. But although this is ok, as we'll need to
> create/drop other kinds of objects (views, procedures, etc), I am for
> finding a more generic way of doing this. So, we've got 2 choices:
>
> * use the XML queries
> * add a modify_schema method, which works more or less like the
> get_schema method (that is, with a GdaParameterList so that you can pass
> any kind of parameter).

The modify_schema method would make the process more symetric (with the
get_schema one).

I definitely don't like the idea of create_table, drop_table, create...,
drop... because this means an ever bigger API which is not the nice way
of doing it.

>
> > * being able to drop tables
> >
> this, again, via a drop_table method, or via the generic modify_schema
> method.
>
> > * being able to create sequences (with initial value and other
> > properties)
> >
> likewise
>
> > * being able to drop sequences
> >
> likewise
>
> > * being able to modify the structure of a table: this one is more
> > difficult since it really depends on the DBMS to which we are
connected.
> > For example rename columns, add or delete columns, add or remove
> > constrains, etc
> >
> hmm, again, using a parameter list, where you can specify all the needed
> parameters ("ADD COLUMN whatever, SET PK, etc), could work.
>

Right.

> > * being able to create/modify user define functions.
> >
> the same. Using modify_schema, we could send the body of the procedure
> as a parameter.

Right.

>
> > If we add the support of indexes and triggers (as there is already for
> > tables, views and sequences), then the following should be done:
> > * being able to create/drop triggers (there is a lot of work on the GUI
> > for this one).
> > * and the same for indexes.
> >
> also, the same, modify_schema or XML queries, as with the others.
>
> > IMO the first thing to be done is to identify all the different
> > individual capabilities you want to implement (we can modify the
> > providers to return the information); for example you need to know if
> > the DBMS supports primary keys, foreign keys, etc to build the GUI to
> > create tables.
> >
> most of this is already supported in the libgda API, although I'm sure
> there will be some missing things. The supports, get_schema and (maybe)
> modify_schema methods are the way we can extend this to support all that
> is needed.

I agree with that.

So we agree to go on a modify_schema method (except of course if anyone
has contrary arguments).

Could you then propose the API and the parameters list, etc like for the
get_schema method to make sure we don't miss anything there. Then the
actual implementation will not be the most difficult thing to do!

Thanks,

Vivien