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 _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
