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

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

> >> 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:
this is already fixed.

> also these ones also.
this is already available, at least the foreign key thing.

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?

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


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