Re: [gnome-db] Re: gASQL status

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2002-05-21 at 16:23, Malerba_Vivien stna dgac fr wrote:
> > 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.
> 
the gasql import in on the gasql branch (cvs co -r gasql gnome-db), and
is ready to start the porting. I changed the autogen.sh and configure.in
files to use the GNOME 2 environment, and then, I had to stop on the
porting due to the usage of libgda in gASQL. That is, you are using
libgda very extensively, and the API has changed a lot for the GNOME 2
version. So, it will need a bit of work.

I am right now studying gASQL code to know how to replace all libgda
usage, so this shouldn't be difficult.

> > 
> > > - 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
> displayed.
> - 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.
> 
ok, I'll take this task for me, although we first need to port to the
new libgda API.

> > 
> > > - 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:
>
libgnomedb depends on Bonobo, but the reason I don't like the bonobo
control idea is that it will need to be done for each provider, which
might be a fair amount of job. Whereas a generic-but-extensible API
would do the job, I think.

> - we need to allow the application to know what options the provider
> accepts to adapt the GUI to what is available only
>
ok, that is perfectly doable. What are the options you're thinking
about?

> - we need a get_rights() method to know what the rights are on a DB's
> object.
> 
yes. We also need to define a generic GdaAccessGrant type to manage the
different types of grants.

> > 
> > > - 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?
> 
> Right.
> 
ok, I also take this task.

> > 
> > > - 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? 
> 
we are starting the implementation in the different providers. The idea,
so far, is to have providers able to identify each row they get from the
database, and if so, have that data model be editable.
As a starting point, I think we'll just make it work with tables (that
is, a "SELECT * FROM table", not JOINs or other schemas). But as soon as
we've got the basic stuff, we can extend it as we like.

That's the best thing about the new libgda: it's so well designed that
it's easy to add new functionality :-)

> > 
> > 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.
> 
yes, in which case, the provider returns FALSE in the is_editable
virtual method of the GdaDataModel class. And so the client knows it
can't update that data model.

> > 
> > 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).
> 
yes, right. That's where the XML queries stuff comes in. We really
should start using it, or Gerhard (who implemented it more than a year
ago) will kill us :-)

> > 
> > 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!
> 
yes, and as your comments are really needed on the new GDA API changes
and future improvements, please set up your GNOME 2 environment and have
a look at it :-)

I've been using GNOME 2 only (no GNOME 1.4) now for over 2/3 weeks, and
it's working great, and all this with binary packages. If you use
debian, add:

deb ftp://ftp.debian.org/debian ../project/experimental main contrib
non-free

to your /etc/apt/sources.list. For RH, in RedCarpet
(ftp://ftp.ximian.com) there are daily snapshots of all of GNOME 2. For
other distros, don't know.

cheers