2006/1/30, Diego Zuccato <[EMAIL PROTECTED]>: > Vivien Malerba wrote: > > >>I'd propose to consider aupport for a tree model, not only for list > >>model. I've already considered the problems, and it seems they can be > [...] > > The GdaDataModel has a list concept and not a tree concept because > > this is the concept behind relational databases (they don't do trees). > I know. But aren't we going to use a higher level when using widgets? > When "presenting" data to the user, readability is all. A tabular format > can be what's in the db, not what the user wants to see (at least not > always).
If you can think of any good data presentation to the user, I'll be happy to include your ideas/code. > > > For the performances problem, the last version of libgda includes two > > features: > > * a GdaDataProxy dete model which allows to define arbitrary size > > "chuncks" of data (by default 300 lines): you give it a GdaDataModel, > > and the GdaDataProxy will only contain 300 lines of that model (of > > course you can then change which 300 lines are displayed). This object > > is used in the form and grid widgets of libgnomedb. > But I have to actually FILL the GdaDataModel from the DB (that can be > quite slow... maybe over a modem connection). > At least there should be a widget that supports it in gnomedb... Or > should every programmer implement his own GdaDataModel->GtkTreeModel > converter? If the data model is requested as a cursor, then only the current row needs to be actually fetched from the database. > > > * There is a provision in the API to access a GdaDataModel using a > > cursor to avoid having to load all the data from the database (the > > cursor is a GdaDataModelIter object). The API still needs to be > > modified (a bit) to specify the DBMS provider if you want a random > > access data model, or a cursor based one when you run a SELECT query. > I'll have to investigate this. But I still think that a GdaDataModelTree > could be really useful. > It could internally use the iterator, but I don't think it's really > needed: run a certain query on expand() and add resulting rows as child > nodes, remove child nodes on collapse(). If there are too many rows > returned by the query, a proxy is useful. Ok, can you propose some API/Code for that? Thanks, Vivien _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
