[gnome-db] Re: gASQL status



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.

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

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

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

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.

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.

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.

cheers



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