Re: [gnome-db] Re: gASQL status

Le dim 19/05/2002 à 16:50, Rodrigo Moya a écrit :
> Hi
> For everybody in the list, we've decided to merge gASQL into the
> gnome-db CVS module, so that gASQL will be the GNOME-DB frontend
> application, since it's better. We are going to put some of the stuff of
> gnome-db into the current gASQL sources, such as the SQL editor, and
> other things.
> This is a conversation between Vivien, current gASQL maintainer, and,
> from now on, new gnome-db maintainer, about the plans of all this.
> On Fri, 2002-05-17 at 18:29, Vivien Malerba wrote:
> > Hi!
> > 
> > I've just commited the last cleanups I wanted to do. The whole thing
> > seems quite stable, and is probably a good base to start the porting.
> > 
> > So, you can now get the CVS version of gASQL (just to make sure, the
> > latest revision of the query.c file is 1.26), and make a new branch in
> > Gnome-DB to start the porting.
> > 
> ok done. Although I screwed it up, since I did the import badly, and all
> the gASQL sources are now in gnome-db HEAD :-( I'm trying right now to
> clean it up, removing the front-end and some other things, and trying to
> leave it compillable.

Ok, I'll set up the latest Gnome2 b5 on my box this week. Tell me when
you think the CVS is in a good state to start working on it.

> > Also, here is a short list of things I think are necessary to implement
> > (or finish implementing) after the porting to Gnome2:
> > - Printing
> >
> this is a must. We need to support printing of data ASAP. One of the
> things on which we could start is on the GnomeDbGrid widget, which will
> allow to print rows of data, which should be a good starting point.
> Anybody with gnome-print experience?
> > - using the Gnome-DB grid
> >
> As soon as I clean up the CVS mess I did, I'll start trying to make the
> current gASQL sources compile on GNOME 2 (which includes porting to the
> new libgda API also), and then, I think we can start switching the grid
> widget in gASQL.


> > - insert the SQL command window
> >
> the widget is in libgnomedb, so I'll wait for you to come back home to
> tell me where to insert it in the gASQL code.

This one's easy in 3/4 steps:
- make or copy a nice icon
- add it to the in the same way as the MainPageTable, MainPageSeq,
MainPageQuery and MainPageEnv which are the 4 widgets which make the
main area in the window. This is done in conf-manager.c, in
build_main_window(), and a new callback function to be needs to be
defined in interface_cb.[hc].
- change the default window size so all the icons in the left bar can be
- MAYBE: modify the gasql.dtd to be able to save the queries done in the
SQL editor at the same time as all the rest.

> > - add users and rights management
> >
> do you agree with the simple API I proposed? With that, having a UI
> would be really simple.

I found the bonobo controls nice (doesn't libgnomedb require bonobo?),
but we can go with your idea if you prefer, with some remarks:
- we need to allow the application to know what options the provider
accepts to adapt the GUI to what is available only
- we need a get_rights() method to know what the rights are on a DB's

> > - add creation of tables and other objects
> >
> we should have all we need in the XML queries. Or, even better, we can
> use the new editable data models (see below).
> > - add creation and removal of databases
> >
> I already added the create_database method on providers, so I'll just
> add a drop_database method, ok?


> > - finish the Glade dialog import
> > - implement the INSERT, UPDATE and DELETE queries as such
> > - ...
> > 
> for this, we should be using the new data models, which is the way you
> get the data from providers in libgda2 (instead of the old
> GdaRecordset). I added last week support for editing those data models
> in this way (for the data model stuff, providers implement a
> GdaDataModel-based class):
> * added a begin_edit signal, for which providers should, for instance,
> start a transaction
> * added a append_row method, so that clients can append a row to an
> existing data model. For this, providers would issue a INSERT command.
> * added a cancel_edit signal, which providers should use to ROLLBACK the
> changes done to the data model.
> * added a end_edit signal -> providers should COMMIT.
> It's missing, as you say, a remove_row method, which should make
> providers issue a DELETE command. Also, a update_row method is missing,
> which should be the equivalent of an UPDATE command.

That's a nice idea and will simplify coding on the client side!
Does it also work with tables' structures and other schemas? 

> For uniquely identifying each row, providers store each row in a GdaRow
> structure, which can be associated a unique ID (OID in Postgres, ROWID
> in Oracle, etc), so that when clients pass back to providers that GdaRow
> to remove/modify, providers can uniquely identify it.

There may be some queries where this will not be possible: queries with
several tables, with sub-queries, functions, strange joins, etc and then
we can use XML queries.

> All this is just started and needs some implementation on the providers,
> but it's just a matter of a couple of days' work. And, using the data
> models, we just avoid the complexity of sending specific SQL commands
> from clients to providers.

Yes, but sometimes I think we will have to (see previous remark).

> Also, for creating tables, we could use the GdaTable class, which is
> also based in GdaDataModel and which represents a table in memory, with
> its definition and its data. We could just build a GdaTable object in
> memory, and use a:
> 	create_table (provider, GdaTable *table)
> method to be implemented for each provider. I think it is an easier
> solution than using the XML queries, which will involve creating the XML
> command, parsing it on the providers, etc.

I really need to see all this, I have not followed the development of
Gnome-DB since the beginning of the Gnome2 porting!



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]