Re: [gnome-db] Re: gASQL status

[Malerba_Vivien stna dgac fr]

Le mar 21/05/2002 à 23:27, Rodrigo Moya a écrit :
> 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.

Yes, see the other mail I'm sending you.

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

This should be fairly easy...

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

Right. I thought that maybe it was a better idea to open a new dialog
window in which to display the SQL console, and so we can have more
space in the dialog than in the gASQL's main window (this means adding a
menu entry or a toolbar icon)?

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

The problem is that it may be difficult to find a common representation
of rights and users management (the DBMS can have VERY different
philosophies about rights and users management). Anyway, let's try the
API way.

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

Several options:
- types of rights (read, insert, update, or read, write, etc);
- if rights are managed at the level of a database, a table or some
columns of a table, sequence, index, vues...
- the kind of rights for a user (create DBs, create other users, change
passwords of other users, etc).
- maybe other ones.

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

Ok.


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

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? 
> > 
> 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 :-)

That is a good idea. With the is_editable() method you mention next, we
have the best of both worlds!

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

Great!

> 
> > > 
> > > 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 :-)

I've been looking forward to it a lot...

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

I use an "old" Mandrake and I used the GARNOME system to build Gnome2.
Now I need to run it and also install libgda and libgnomedb.

Cheers,

Vivien