I'm working in a set of GObject based on Vala (witch can be used in C), to get information from tables, present in master. You can see the code in tests/vala/CheckTable.vala, because I haven't written an example in samples/vala jet.
Even I think that makes easy to handle metainformation about a table by using just an update() method to retrieve them from database, hinding most of GDA Meta information access to each meta table, the performance is really bad. I found a bug in PostgreSQL provider to update some specific meta information tables, reported in *Bug 670859*<https://bugzilla.gnome.org/show_bug.cgi?id=670859>. Then I added some code in Unit Test to shows up all errors in this providers at: http://git.gnome.org/browse/libgda/commit/?id=42cfaa6e0c540f36750c6365213a53ea6c716c9b I was thinking on exposes some Meta Information retrieval from Providers to get direct access to it. With this my effort to retrieve meta information could be faster (no internal database is updated) and mapped directly to your needs. I mean: a) Get meta information directly from providers could help in performance b) You can "map" this information to your application's model. For (a) we need to expose most of the GdaMetaStore functions to the user, adding wrappers functions and return GdaDataModel objects. Each provider execute a series of SELECT statements to get its own information, then it is saved to a GdaMetaStore database in SQLite, this takes some time. We can add methods to expose that information to the user directly, without update GdaMetaStore. For (b) you can "save" this information in the way you need for your application/library. No internal metadata update is required if you access directly from database on demand. May the model in GdaData extensions could be useful. In GdaData, I've added some objects to manage information as easy as possible (unless thats the plan), for tables you can call update() method and you'll get all meta information updated, mapped to properties and methods (even you can setup your own and use append() to create a new table in the database!). This effort can take advantage of using direct access to Provider's information, because now it needs GdaMetaStore to be updated (taking a long time to do so), and maps directly to a GdaData.DbTable interface (implemented by GdaData.Table actually), with method and Collections to get fields' information, keys, and dependencies. GdaData is located at libgda/data. 2012/3/9 Murray Cumming <murr...@murrayc.com> > On Fri, 2012-03-09 at 12:16 +0100, Piotr Pokora wrote: > > Hi! > > > > I am quite confused with meta store functionality. > > First, all operations are very slow (if you compare to direct RDBM > > queries) > [snip] > > That is why I update only parts of the metastore in Glom. I added > methods to libgdamm to make this easier: > http://git.gnome.org/browse/libgdamm/tree/libgda/src/connection.ccg#n339 > http://git.gnome.org/browse/libgdamm/tree/libgda/src/connection.ccg#n373 > http://git.gnome.org/browse/libgdamm/tree/libgda/src/connection.ccg#n394 > > > -- > Murray Cumming > murr...@murrayc.com > www.murrayc.com > www.openismus.com > > _______________________________________________ > gnome-db-list mailing list > gnome-db-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-db-list > -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE)
_______________________________________________ gnome-db-list mailing list gnome-db-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-db-list
