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

[Rodrigo Moya <rodrigo gnome-db org>]

On Mon, 2003-06-23 at 15:57, Vivien Malerba STNA 7FD M204 wrote:
> > 
> > > - 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.
> 
oh, ok

> > 
> > > - 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.
> 
ok, understood.

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

> > 
> > > - 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.
> 
oh, would be good if you could try the modifications and see if they
compile on GTK-only linux system.

> > 
> > > - 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:)
> 
libgnomedb has nothing about reports yet :-( But libgda does, and the
idea is to provide a report preview (and maybe also an editor) in
libgnomedb.

> 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.
> 
sorry, I didn't mean that, I was only concerned about what your ideas
were.

> > 
> > > 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.
> 
what about putting it in CVS? Maybe we can out it in the mergeant
module, as a non-built directory?

cheers