Re: [gnome-db] Re: post-GUADEC plans

[Vivien Malerba STNA 7FD M204 <vivien malerba aviation-civile gouv fr>]

Le lun 23/06/2003 à 14:22, Rodrigo Moya a écrit :
> > Right, Mergeant is not yet ready for 1.0 release (it still has many
> > crashes, it can't do a lot of things, etc). In fact I'm planning a
> > complete rewrite of it using a new library I'm currently writing (which
> > I've, suprisingly, named libmergeant).
> > 
> oh, how far are you on that rewrite? Having a library would be really
> good to provide, apart from mergeant, components that operate, within
> nautilus, with mergeant files.

Yep, that'll be possible and quite easy to do.

> 
> > I plan to make a bit more work on that lib and release it soon.
> > Basically the new lib will have the following features:
> > - uses libgda for any access to the DBMS
> >
> cool. I find the layers in mergeant a bit redundant. So letting libgda
> do the job will reduce a lot of code and a lot of crashes.

So far libgda is used for any DBMS access, and to represent data models
(GdaDataModel) and values (GdaValue).

> 
> > - creates a memory structure for all the DBMS objects (data types,
> > functions, aggregates, tables, views, tables fields, some constraints so
> > far)
> >
> can't this be done using data models instead of having another in-memory
> structure? Think that the data models keep the data also in memory, so
> it might be redundant.
> 
> Also, using data models directly will allow mergeant to be notified
> (once we implement it) when the data model changes.

I have created a whole new lot of objects and interfaces because I
needed some special features regarding objects management and also
because there are quite a lot of objects which you can't really put in a
list model. The query object is a good example:
- it has fields of several different types (something like 5 or 7), some
also using other fields themselves
- it has targets which reference either tables, views, or other queries
- it has joins between targets (the joins are organized as lists of
lists to reflect some properties)
- the conditions are a tree where each leaf represents a field in a
query
- it has sub queries

Data models are used when real data (from the database) is manipulated.


> 
> > - creates memory structures for any type of DML query (even complex ones
> > with sub-queries) and can render them to SQL (and hopefully to XQL
> > later).
> >
> cool
> 
> > - each query can have execution parameters which must (or may) be
> > provided before query execution
> >
> also cool
> 
> > - has a powerfull widget to display and select most of the types of
> > objects in libmergeant (table, fields, data types, queries, etc)
> > - has several widgets to make it easy to have a form and a tabular views
> > of data
> >
> I think we could have this in GnomeDbForm, in libgnomedb. If we let the
> data management to libgda/libgnomedb, that should be possible. Or are
> you thinking on other features only available in mergeant?

These widgets don't exist yet, but I've already thought about how to do
them. I don't know the GnomeDbForm widget all that much, but I don't
think the widgets I'm talking are a replacement for that widget: the
goals are differents.

Libmergeant can only be used with an overhead which libgnomedb does not
have: it _requires_ that a specific memory structure exist before doing
anything, which is not the case of libgnomedb. That structure (which is
automatically extracted and updated from the database itself and saved
as XML) holds precise database specific information.

The benefits of this overhead are that the widgets are completely aware
of the possibilities of the database, which is not the case, AFAIK, for
libgnomedb, and can adapt themselves to the data.

Libmergean't form is a good example as it can make a good use of primary
keys, foreign keys, not null constraints, and data types.

My point of view here is that libgnomedb and libmergeant are really two
different and complementary libraries.

> 
> > - has a plugin system to extend the default widgets used to enter or
> > modify data, depending on the data type of the manipulated data.
> >
> also something that could be in libgnomedb.

Yes, that could be done, since for that part I'm only using GdaValue and
GdaValueType and nothing specific to libmergeant.

> 
> > - uses XML for all the storage issues.
> > - can optionnaly use libgnomedb for some better features.
> >
> why optionally? I would vote for putting all generic features in
> libgnomedb.

Right now because I can't install libgnomedb on my machine because it
has dependencies on other gnome libs I don't have (and can't install)!
I haven't yet tested the latest modifications to make it work with only
gtk, so this is why it is still optional.

> 
> > - has an up-to-date (well almost) documentation using gtk-doc
> 
> > I plan then to extend it to have more graphical components (like a
> > specialized canvas), DDL queries and reports generation.
> > 
> again, the reports UI should be in libgnomedb, based on the
> libgda-report we've got in libgda. Mergeant, IMO, should just provide a
> good frontend for all that, that is, use them in a coherent UI.

Well, I haven't defined anything for the reports, and I have not looked
at what libgnomedb already does, so these are just ideas. If libgnomedb
already has some stuff, then I'll use it directly in Mergeant:)

I really don't want to write my own things when they are available in
libgda or libgnomedb, and I don't think I've done that with libmergeant.

> 
> > When that lib is ready, a rewrite of mergeant using the lib will not be
> > very difficult as most of the features currently provided by mergeant
> > will be in libmergeant. Libmergeant can of course be used outside the
> > scope of mergeant itself.
> > 
> > Maybe, if you find the library usefull and if the lib is stable enough
> > (which I think will be the case), we can then make common releases of
> > libgda/libgnomedb/libmergeant/mergeant, no?
> > 
> yes, of course. The only reason to separate the releases right now would
> be to release libgda/libgnomedb 1.0. We can still do coordinated
> releases, even if the version numbers don't match.

Ok, for the time being, just make a release of libgda and libgnomedb
(mergeant is not useable in that state, anyway).

If you want, I can send you my current version of libmergeant, if you
want to test it. I haven't made it public yet because it does not show a
lot of things.

Cheers,

Vivien