Re: Work on pgAdmin3
От | Dave Page |
---|---|
Тема | Re: Work on pgAdmin3 |
Дата | |
Msg-id | 03AF4E498C591348A42FC93DEA9661B885EB@mail.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Work on pgAdmin3 (Andreas Pflug <Andreas.Pflug@web.de>) |
Список | 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 по дате отправления: