Re: [gnome-db] gda and PostgreSQL schemas

Vivien Malerba ha scritto:

Seen no answer so far... Since the first was so fast, I think the second got lost somewhere... Or just hit the trashcan... :)

[...]It could be really
useful a "tree" view instead of a "list" view. And it seems it couldn't
recognize "ltree" type used in some tables (correctly installed, since
Can you send me the dictionary it made with that data type? I've never
used that data type myself.
[Stripped attaches sent in the other mail. Better not to post it in the list. If it got lost, I'll resend. The following steps are enough to reproduce, anyway]
In a simple case (no schema), it works.
$createdb test
$psql test
test=#create table prova (path ltree, descr char(30));

If I first create a schema, it stops working.
$createdb test2
$psql test2
test=#create schema test;
test=#create table test.prova (path ltree, descr char(30));

(when trying to load this db metadata, mergeant says it can't find ltree data type).

PG doesn't complain), leading to a corrupted dict file.
In my program I'm using many cross-schema queries. Should I expect troubles?
You may have some trouble if you have tables with the same name in
different schemas and if these schemas are part of the search_path...
I have on my todo list to handle correctly schemas...
What if I use the (I think PG-standard) schema.tablename notation?

PS: is there something "standard" to handle tree structures
(efficiently... can't load all 20K rows at start...) or should I create
my own widget?
Which kind of tree structures do you have? Is it to be used with the
ltree data type?
In my case, yes. I'm using ltree to handle variable-depth trees (geographic position of caves: continent->state->region->city->... ). But a general-purpose widget could be useful for many things: directory browser (a filesystem is a DB, after all... :) ), db-schema-table-field & so on.

I already have coded a GTK_TREE_STORE filler: it's a callback for every row returned from the query. It receives the current row and the tree_store to update, and appends to the correct parent the new data (using "ORDER BY path USING <@", I could get O(nlogn) complexity, while in general it's O(n2), but maybe using hash tables it's around O(n)...). The drawback is that it fills the WHOLE tree... Having around 20K locations you see it becomes quite unmanageable (some hours just to start up)... What could be really useful is an "infrastructure widget", that gets filled while the user proceeds: when he clicks "continent", he gets all the nations in that continent & so on for regions in nations, cities in regions... Such a widget (really just a gtk_tree_view with some extra data attached) should be in gnome-db, IMVHO.
What do you think?


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