Re: [gnome-db] What DWI does [was Re: GnuCash page on GO site]

[Rodrigo Moya <rodrigo gnome-db org>]

On Mon, 2004-03-08 at 03:31 +1300, Andrew Hill wrote:

> Rodrigo Moya wrote:
> 
> >On Sun, 2004-03-07 at 20:30 +1300, Dru wrote:
> >  
> >
> >>gnomedb widgets need ability easy ability to popualte widgets from 
> >>non-libda sources (proberly already possible).
> >>
> >>    
> >>
> >you just have to write a GdaDataModel-based class that access the non-
> >libgda sources. Or you can just create a GdaDataModelArray, for
> >instance, from the non-libgda source. Not sure if those are the easiest
> >ways, do you have any better idea?
> >
> I thought about a bonddb -> GdaDataModel mapping tool.  Would proberly 
> work as long as signals still work well on widgets and its easy to get 
> information back out of gdadata.
> 
signals about the model modifications? If you do your own GdaDataModel-
based class, you'll have to emit the signals yourself, but if you use
one of the existing data model classes, that is done for you
automatically.

> >> with possible tie-ins on 
> >>sorting etc.  libgda api needs to be able to return field information 
> >>attributes.
> >>
> >>    
> >>
> >it already does return a lot of information per field. I know there are
> >still some of the bugs you opened not fixed. Is that the missing
> >information you're talking about?
> >  
> >
> Yip. this is the major one:
> http://bugzilla.gnome.org/show_bug.cgi?id=81590
>
this is already fixed.

> also these ones also.
> http://bugzilla.gnome.org/show_bug.cgi?id=81589
>
this is already available, at least the foreign key thing.

> http://bugzilla.gnome.org/show_bug.cgi?id=81587
> 
will work on this one.

> I was gonna add this to bugzilla at some point, here are some useful 
> libpq functions i currently use. I can write code to get around lack of 
> them.
> |
> PQftable();
> Allows you to find out which table a field belongs to in an sql 
> statement. Way to get around it is to use the libsql parser and guess.
>
this is already guessed, not sure why PQftable is not used. Will check.

> >> API is a bit complex and messy compared with other simplier
> >>data access libraries.  It has other things in there that proberly 
> >>shoulnd't be sitting in libgda, though i imagine this is because of 
> >>having to support a range of datbases and not just simply SQL.
> >>
> >>    
> >>
> >could you ellaborate on this please? I'd like to hear any comments about
> >what you think is wrong
> >  
> >
> Am i allowed to suggest breaking api compatiability?
>
yes, for for libgda 1.2

>   your current 
> libgda api is rather big. Its kinda like everything low level ended up 
> there.
>
which low level bits do you think shouldnt be exposed?

>  I think you should have a lower level library for sql queries or 
> move some stuff out of libgda. a libgda_sqldb
> library? (could have seperate directories for files and statically link 
> them into one libgda library)
> And its got a lot of complexicties to it. It would be nice to just have 
> something sweet and simple and fast.
>
which complexities?

> Its a bit confusing on initialisation of connections, do you use 
> GdaConnection or GdaClient to establish connections?
>
GdaClient is the entry point for getting connections.

> What does a GdaDataModel contain?
> 
data from the underlying database, in rows x columns form.

>  Does it store information not 
> recordset related, ie stuff for libgnomedb, should they be another new 
> object which is higher up in api. the cvs and xml stuff, could that be 
> in a file from gdadatamodel?
>
sorry, I dont understand what you're trying to say.

> The append row,insert stuff, does that stuff work, ie do a select 
> statement, then are able to append and update rows?
>
work on that is being done for 1.2, so yes, once done, it should work

> I found this quite complicated to write and many c files. 
> The xml stuff i've never used.
>
that is the only extra complexity I can think about. We should probably
move that to its own library, although it makes a lot of sense to be in
libgda. We could probably reduce the number of .h files.

>  it looks useful but could it be in a 
> libgda_xml library?
>
yes, it could, not sure if it's worthy though

>  Its got its own connectors functions etc. If you 
> using xml databases shouldnt it be a provider in itself?
>
the XML functions are related to parsing and building XML queries, not
XML databases.

>  And have a 
> libgdb_xml for doing xml queries.
> if your connected to a non sqlstandard langauge, can it convert sql to 
> standard sql if you run a sql statement?
>
yes

>  Ok this doesn't make things 
> simplier but more complicated.  but it makes life a lot easier.
> Is gda-value needed?
>
we've thought about using GValue, but that would need us to be able to
extend it.

>  What does gda-parameters do for sql statements?  
>
it allows you to send arguments to SQL commands (INSERT INTO table
VALUES (:id, :name)

> Whats difference between gda-command and gda connection for sending 
> commands to db?
>
GdaConnection manages a connection to a data source, GdaCommand contains
a command and related options to be sent to a GdaConnection to obtain/
modify data

>  Do gda-logging and gda-error both perform similar functions?
>
gda-logging should probably be hidden, and not installed at all. It
should only be used internally.

> Notifiers are nice but i'd like it to happen manually. Not automatically 
> update a gdadatamodel. leave it in the log or connection info that this 
> record set is in need of a refresh.
>
that would be a nice addition, although we'll still want the automatic
update. But yes, we could have a gda_data_model_dont_refresh function to
disable automatic updates.

>   Or set callback functions on 
> notifiers (proberly does this i just dont know how). 
>
connect to GdaDataModel's signals

> gdaexport properly doesn't need to be in access library either. thats 
> more of a tool.
>
yes, it should also be hidden

>   likewise for GdaSelect.
>
no, that's the client-side SQL parser, which allows to do queries
against a set of in-memory data models.

> Memory freeing api functions. Where are they?  Consitent names for 
> freeing where possible.
>
g_object_unref for GObject-based classes. For the others, there is
always a _free function.

> Unforuntly most libraries leak memory. I have this bond app + gtk 1.4 + 
> libpq, and it very slowly leaks memory, a lot less than bond2 app + gtk 
> 2.4 + libpq however. Anyway, the programme runs for about 80 days or so 
> under heavy usuage until it runs out of memory (only 64mbs of ram on 
> machine its on). anyway , point is, memory leaks are nasty. esp when 
> apps stop segfaulting and users never quit out.
> gtk-config, all of that does config file handling?
> 
right, they're nasty, that's why there are tools like valgrind, memprof,
etc to find the leaks. You should probably run your apps via those, to
find out the leaks.

cheers