[gnome-db] RE: gASQL

[Rodrigo Moya <rodrigo gnome-db org>]

[Adding gnome-db-list to CC]

On Wed, 2002-09-04 at 14:19, Vivien MALERBA wrote:
> Le mer 04/09/2002 à 13:24, Victor Vatamanescu a écrit :
> > Hi there!
> >
> > I would be most interested in adding database schemas management (tables,
> > sequences, indexes, triggers,
> > users, users rights, etc) and I would like to start as soon as possible.
> >
> > Thank you very much,
> > Victor Vatamanescu
> >
> 
> 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).

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

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

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

> Then you need to think about where to put the GUI and how (separate
> dialogs, etc). For that purpose, you can use Glade to make some mockups.
> 
once the low level stuff is well defined, I'm sure the GUI would be no
problem.

cheers