Re: Work on pgAdmin3 - Mailing list pgadmin-hackers

From Dave Page
Subject Re: Work on pgAdmin3
Date
Msg-id 03AF4E498C591348A42FC93DEA9661B885EB@mail.vale-housing.co.uk
Whole thread Raw
In response to Work on pgAdmin3  (Andreas Pflug <Andreas.Pflug@web.de>)
List pgadmin-hackers

> -----Original Message-----
> From: Andreas Pflug [mailto:Andreas.Pflug@web.de]
> Sent: 27 March 2003 11:36
> To: Dave Page; pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] Work on pgAdmin3
>
>
> I'm tracking this list since Jan 24, haven't seen something about
> cacheing. Did I miss it?
>

It was in amongst a bunch of other subjects in one email thread between
me & Keith. Basically, in pgAdmin II, pgschema provides a single object
hierarchy that can be used by all parts of pgadmin. This meant that as
the hierarchy was built on demand, it happened for any part of the
application that accessed it. The difficult bit was synchronising the
pgschema hierarchy with the treeview.

In pgAdmin III, that problem doesn't exist because the object hierarchy
is maintained by the treeview which stores each object as a class
derived from wxTreeItemData (iirc). However, this method relies on the
user to click the treeview to build the hierarchy, so something like
Keith's QBE tool cannot use the hierarchy to find available tables/views
etc because they may not be there if the user hasn't browsed to them.
This of course also applies to other dialogues that may provide lists of
objects, such as create operator, create function etc etc.

I have yet to figure out a solution (other than return to the old style
design), and I'm guessing Keith hasn't either as he hasn't said so.

Regards, Dave.


pgadmin-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: WARNING: CVS Server potential downtime
Next
From: efesar
Date:
Subject: Re: can't compile