Just a heads up for whoever is thinking about doing this. I've written stuff like this in both python and C and noticed some interesting results.
First of all, I went the route of writing a custom GtkTreeModel. This way I had full control of tree iteration. You will probably want to do the same. Especially since this allows lazy loading. For example: For the iter data, you could store the rows offset. In PostgreSQL and SQLite, using the row OID works great as it is the fastest way to access any record. However, using a system that allows you to determine the next rows Iter data without a new query is probably a good idea. If I remember correctly, I got my best performance by mixing the two ideas; Batching queries to get the next 10 rows OIDs. I also noticed that for some reason, when setting the model, a GtkTreeView will try to scan the entire result set. I think this is actually a GtkCellRendererText trying to figure out sizing but I haven't looked at it too closely. You also may want a tunable cache to lower the number of queries. I used a LRU which worked pretty decently . Just remember to expire values on updates. Food for thought. -- Christian On Jan 6, 2008 8:21 AM, Jacek Ruzyczka <[EMAIL PROTECTED]> wrote: > Am Sonntag, 6. Januar 2008 00:49 schrieb Adam Tauno Williams: > > When using a TreeView to display data from an RDBMC I think it is much > > more common that the subordinate entries are the result of a foreign key > > relation (join or secondary select). > > > This is what I have in fact sketched here. Typically, when you have a > hierarchy of categories, you would add an FK column pointing to the PK column > in the same table. > > Regards > Jacek Rużyczka > > _______________________________________________ > Gtk-sharp-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/gtk-sharp-list > > _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
