Re: [gnome-db] Tree-structured data

[Vivien Malerba <vmalerba gmail com>]

2006/1/30, Diego Zuccato <diego otello alma unibo it>:
> 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