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

[Andrew Hill <dru treshna com>]

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.

> > 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
also these ones also.
http://bugzilla.gnome.org/show_bug.cgi?id=81589
http://bugzilla.gnome.org/show_bug.cgi?id=81587

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.
PQoidValue();
Gives you the oid of the last record inserted. Can be got around if you 
know the primary keys and the defaults of the primary keys in advance. I 
explained details of this in previous email.

|

> > 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?  your current 
libgda api is rather big. Its kinda like everything low level ended up 
there. 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.
Its a bit confusing on initialisation of connections, do you use 
GdaConnection or GdaClient to establish connections?
What does a GdaDataModel contain? 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?
The append row,insert stuff, does that stuff work, ie do a select 
statement, then are able to append and update rows?
I found this quite complicated to write and many c files. 
The xml stuff i've never used. it looks useful but could it be in a 
libgda_xml library? Its got its own connectors functions etc. If you 
using xml databases shouldnt it be a provider in itself? 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? Ok this doesn't make things 
simplier but more complicated.  but it makes life a lot easier.
Is gda-value needed? What does gda-parameters do for sql statements?  
Whats difference between gda-command and gda connection for sending 
commands to db? Do gda-logging and gda-error both perform similar functions?
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.  Or set callback functions on 
notifiers (proberly does this i just dont know how). 
gdaexport properly doesn't need to be in access library either. thats 
more of a tool.  likewise for GdaSelect.
Memory freeing api functions. Where are they?  Consitent names for 
freeing where possible.
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?