Re: [gnome-db] Tree-structured data



2006/1/26, Diego Zuccato <diego otello alma unibo it>:
> Hello.
>
> IIUC the API is in a changing state.
> 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
> solved in a general way using a "find_parent" callback that returns some
> kind of pointer to the parent node of the "to be appended" row. Even
> better could be support for "load on demand", so that data is actually
> read from db only when needed (for example when a branch is expanded,
> via a callback that receives a reference to the parent node). I've
> already done something similar in a program I'm working on, so some code
> is already available (even if it needs to be adapted, since I'm using
> some direct calls to the DB).
> When you have something like 100k rows, using a tree is the only way to
> load the data in a reasonable time. I've done some testing, and filling
> a list (well, actually DISPLAYING it on Gtk+2) with 10000 rows took
> quite a long time (hours), while splitting all the data in a tree with
> about 1000 elements per node took just seconds... [could retrieve actual
> figures, if needed]
>
> Waiting for feedback...

The GdaDataModel has a list concept and not a tree concept because
this is the concept behind relational databases (they don't do trees).

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.
* 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.

To test the grid widgets presents "chuncks" of data, please run the
testing/test-dyn-widgets program as:
"./test-dyn-widgets -t 9" and select the "products table" which
contains some 3000 items.

Except for the performances and "readability" of the data, I don't see
how a tree based data model could be used in a general way.

Cheers,

Vivien



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]