help for "quick search" - Mailing list pgadmin-hackers

Dear Dave and List,

Thank you very much you quick and detailed answer.
We will try to follow your comments so I'll keep talking on hacker's list.
We would accept all your comments on functionality.

Does anybody on the list know if there is possiblity to use WxTree in
a way that one can disable /enable
of displaying specific branches or leaves?
Because Akos hasn't found a way to do so, hence we turned to a solution in which
we create a copy of the original tree containing the elements to be
displayed (the search
result set) only.

Levente

On Friday 06 March 2009, you wrote:
> Dear Levente,
>
> [Please keep any future technical discussions on our mailing lists
> rather than private mail. As an open source project, we prefer to keep
> any development discussions open].
>
> On Thu, Mar 5, 2009 at 11:05 PM, Levente Torok <toroklev@gmail.com> wrote:
> > Dear Dave,
> >
> > My student, Akos is working on the project of creating a quick search bar on
> > the object browser tree in pgadmin as you already have heard it before.
>
> I wasn't aware this was a student project, but yes, I recall the discussion.
>
> > The screenshot he made and sent you formerly certainly reflects a mid stage
> > of his work. The current one is the same from this aspect.
> > He plans to replace your original object browsing window with his one
> > that you see floating nearby (yet) on the new screenshot, too.
> > Nevertheless he will still have your object browser tree in memory invisibly.
> > This emobidies corpus of the search.
>
> OK. That sounds ambitious, and something that could easily be
> implemented in a way that we don't like. It could however, provide
> some useful infrastructure for another project that's been on my TODO
> list for some time. I would strongly suggest that patches are sent to
> the -hackers list on a regular basis so we can ensure the code that
> Akos is writing is going in a direction that the project is happy
> with. Not doing that, is probably the number one reason why patches to
> pgAdmin (or PostgreSQL for that matter) get rejected  - community
> participation is critical in our development model.
>
> > You had a comment on his initial design that the search cannot be populated to
> > elements not loaded from the database and there should be a possibility to filter
> > by object type to accelerate the execution.
> >
> > According to my use of the interface I would be very happy to search only for those
> > elements that are already in the memory. And this isn't very much in conflict with the
> > concept of your software since the user is forced to push the "refresh" button regularily.
> > So the notion of the loose connection to the database should already be recognized
> > by the user so I suggest not to have a filter for types.
>
> You should only ever have to 'refresh' if you manually make changes to
> objects, for example from psql, the Query Tool, or from another
> machine. Any changes made through the main pgAdmin UI should be
> automatically reflected in the treeview.
>
> The reasons for the way this works is largely historical - pgAdmin was
> originally developed when I often accessed remote servers over slow
> modem connections where it was too expensive to refresh objects on
> every click.
>
> The suggestion that the search can be confined to objects that are
> already in memory is one that I certainly do not agree with. The whole
> reason why a user may want to search is because they cannot find an
> object, and there's a good chance that is because it is not yet on a
> part of the tree that has been loaded. Offering a search facility
> which may or may not find a specific object based on the browsing user
> has already done in the session will certainly break the Principle Of
> Least Surprise and I'm certain it would result in additional traffic
> on our support list.
>
> I would suggest the following approach:
>
> - Restrict searching to nodes underneath the currently selected node.
> This will minimise the search space as much as the user allows.
>
> - Do not allow any searching the would include multiple databases in
> the search space - i.e. disable searching below the Servers, Server
> and Databases nodes.
>
> - Only search the object types that are enabled under File -> Options.
>
> - Offer a filter to allow the user to search only specific object
> types if they wish, to minimise loading requirements on the first
> search. This might be more trickier to implement than is immediately
> obvious (because the code will need to figure out where in the tree
> certain object type might end up). I would consider this optional,
> based on how effective the measures above turn out to be.
>
> > On new the current screenshot, the search and the tree organization from results set
> > seems to be working finely but he gots stuck with copying elements from the original tree.
> > He says he found mails on mail-lists which explains that it is impossible to copy
> > an object from the obj bro tree along with its relation to another wx container such as a tree.
>
> I'm not entirely sure what you mean. Can you provide sample code and
> references to the past emails please?
>
> > The reason of my mail is ask for a little help on the concepts we should follow since he has put
> > an enormous amount of work into this project but seems to fail if this issue cannot
> > be solved somehow. I am affraid we don't understand something very deep the design of PgAdmin
> > so please let us know your comments on the idea of copying the tree and and emulating if it
> > were the original tree while replaces the original your tree.
>
> As I said above, I'm not against the idea as it will be useful for a
> project of my own - however, the whole reason why I haven't got around
> to implementing that project yet is the complexity of this problem.
> That said, I'm not sure I understand why you need to separate the data
> from the tree in this case anyway. It's trivial to programatically
> populate parts of the tree when required, and should also be fairly
> simple to search once populated.
>
> Regards, Dave.