Thread: help for "quick search"
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.
On Sun, Mar 8, 2009 at 12:11 AM, M@rton Akos <makos999@gmail.com> wrote: > 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. I don't believe that is possible. You shouldn't be implementing the search result display in that way anyway in my opinion - what you're implementing there is a filter, not a search. I would expect results to be listed in a window, and a double-click on any row should select and bring the corresponding node into view on the treeview. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Sun, Mar 8, 2009 at 10:17 AM, Levente Torok <toroklev@gmail.com> wrote: > On Sunday 08 March 2009, you wrote: >> >> I don't believe that is possible. You shouldn't be implementing the >> search result display in that way anyway in my opinion - what you're >> implementing there is a filter, not a search. I would expect results >> to be listed in a Window, and a double-click on any row should select >> and bring the corresponding node into view on the treeview. >> > > I believe it would require too much user interaction and no benefit compared to > manual search. I'm guessing you never worked on a large database? :-) > I suggest not even to have a search button but do filter operating > on-the-fly. This should be similar to the quick search of new synaptic (in ubuntu). In that case you need to decide whether your are building a filter or a search tool. A search tool is what we have on the todo list - a filter is likely to be much harder to implement and not be as useful - consider a search on a fairly common string. The search tool will list all the results in one place and allow you to jump to a specific one, having shown other information such as owner and comment in the results list, whilst a filter could still leave results scattered in various places in the tree and will require you to select each tree node in turn to examine the additional detail you need to determine which is the item you're interested in. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Sunday 08 March 2009, you wrote: > On Sat, Mar 7, 2009 at 11:59 PM, Levente Torok <toroklev@gmail.com> wrote: > > Dear Dave, > > > > 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. > > I don't believe that is possible. You shouldn't be implementing the > search result display in that way anyway in my opinion - what you're > implementing there is a filter, not a search. I would expect results > to be listed in a Window, and a double-click on any row should select > and bring the corresponding node into view on the treeview. > I believe it would require too much user interaction and no benefit compared to manual search. I suggest not even to have a search button but do filter operating on-the-fly. This should be similar to the quick search of new synaptic (in ubuntu). Lev -- Blogger of http://fapuma.blogspot.com
On Sunday 08 March 2009, you wrote: > On Sun, Mar 8, 2009 at 10:17 AM, Levente Torok <toroklev@gmail.com> wrote: > > On Sunday 08 March 2009, you wrote: > >> > >> I don't believe that is possible. You shouldn't be implementing the > >> search result display in that way anyway in my opinion - what you're > >> implementing there is a filter, not a search. I would expect results > >> to be listed in a Window, and a double-click on any row should select > >> and bring the corresponding node into view on the treeview. > >> > > > > I believe it would require too much user interaction and no benefit compared to > > manual search. > > I'm guessing you never worked on a large database? :-) > > > I suggest not even to have a search button but do filter operating > > on-the-fly. This should be similar to the quick search of new synaptic (in ubuntu). > > In that case you need to decide whether your are building a filter or > a search tool. A search tool is what we have on the todo list - a > filter is likely to be much harder to implement and not be as useful - > consider a search on a fairly common string. The search tool will list > all the results in one place and allow you to jump to a specific one, > having shown other information such as owner and comment in the > results list, whilst a filter could still leave results scattered in > various places in the tree and will require you to select each tree > node in turn to examine the additional detail you need to determine > which is the item you're interested in. > Ok. Call it as a filter but function as a search :) Look. The problem is the following. We have exteremely large number of items in the obj browser tree. In general, this is very unpleasant to manually search for items in the tree even if we know the exact name of it. For this reason we usually use psql console since it has mighty tab completion. If only such a quick filtering functionality would be integrated in the GUI, it would be extremely helpful. (not to mention the console integrated in the pgadmin) I wouldn't like to do any click or key hit, if unneccessary and the synaptic's quick seach such as: http://www.basicconfig.com/files/imagepicker/j/jinlusuh/Screenshot-Synaptic%20quick%20search%20seamonkey.png are good examples of this but Compiz config, or KDE's control center are worth considering too. And this is what the project is aiming at. Lev -- Blogger of http://fapuma.blogspot.com
On Sun, Mar 8, 2009 at 11:31 AM, Levente Torok <toroklev@gmail.com> wrote: > Look. The problem is the following. > We have exteremely large number of items in the obj browser tree. > In general, this is very unpleasant to manually search for items in the > tree even if we know the exact name of it. For this reason we usually use > psql console since it has mighty tab completion. > If only such a quick filtering functionality would be integrated in the GUI, it would be extremely helpful. Except that, per my previous comments, it's like to be a lot more code and less useful than a true search. > (not to mention the console integrated in the pgadmin) It can easily be in 1.10, using the plugins mechanism - in fact integrating psql is our standard example. > I wouldn't like to do any click or key hit, if unneccessary and the synaptic's quick seach such as: > http://www.basicconfig.com/files/imagepicker/j/jinlusuh/Screenshot-Synaptic%20quick%20search%20seamonkey.png > are good examples of this but Compiz config, or KDE's control center are worth considering too. I understand what you are suggesting, but believe that in many cases *more* clicks will be required. A search results listing can easily show additional pertinent information about each matching object such as it's type, owner and comment. With a filter, you can view the type through the location on the tree, but that might require scrolling. For information such as the owner or comment, you must locate and click *every* object until you find the one you actually want. In addition, you could easily further refine a search results listing by sort by different columns, or applying filtering to the results list (for example, to only show objects owned by a certain user). That is much harder to present in a UI in the design you propose. What do others think? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Monday 09 March 2009, you wrote: > On Sun, Mar 8, 2009 at 11:31 AM, Levente Torok <toroklev@gmail.com> wrote: > > > Look. The problem is the following. > > We have exteremely large number of items in the obj browser tree. > > In general, this is very unpleasant to manually search for items in the > > tree even if we know the exact name of it. For this reason we usually use > > psql console since it has mighty tab completion. > > If only such a quick filtering functionality would be integrated in the GUI, it would be extremely helpful. > > Except that, per my previous comments, it's like to be a lot more code > and less useful than a true search. > > > (not to mention the console integrated in the pgadmin) > > It can easily be in 1.10, using the plugins mechanism - in fact > integrating psql is our standard example. > > > I wouldn't like to do any click or key hit, if unneccessary and the synaptic's quick seach such as: > > http://www.basicconfig.com/files/imagepicker/j/jinlusuh/Screenshot-Synaptic%20quick%20search%20seamonkey.png > > are good examples of this but Compiz config, or KDE's control center are worth considering too. > > I understand what you are suggesting, but believe that in many cases > *more* clicks will be required. A search results listing can easily > show additional pertinent information about each matching object such > as it's type, owner and comment. With a filter, you can view the type > through the location on the tree, but that might require scrolling. > For information such as the owner or comment, you must locate and > click *every* object until you find the one you actually want. I am not objecting to prefilter for types. It makes sense to search for comments but not as a quick search. E.g. Synaptic searches for package names exclusively but not the description fields. > > In addition, you could easily further refine a search results listing > by sort by different columns, or applying filtering to the results > list (for example, to only show objects owned by a certain user). That > is much harder to present in a UI in the design you propose. Now I got to understand your UI problem!. There two approaches to this: - One is what KDE control center does but I prefer the other one. This is that: we have the original tree with all objects but once we enter something in the quick search window the tree will be reduced to branches that appear under those objects that contiain the entered search phrase in any fragment. -The KDE's approach is to generate a list of the items with partial matches. I prefer the former but may be more GUI space wasting than the latter one. > What do others think? Really, what do others think??? ---------------- Question: I cannot start up my pgadmin3. I have the following strace running infinitely but slowly: poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN, revents=POLLIN}], 2, 499) = 1 read(7, "\10\3\213\nn\311\307\2Y\0\0\0A\0\240\0\0\0\0\0\261\001"..., 4096) = 96 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) gettimeofday({1236597834, 122116}, NULL) = 0 poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 0) = 0 poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 0) = 0 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 0) = 0 select(8, [7], [7], NULL, NULL) = 1 (out [7]) writev(7, [{"\2\7\4\0A\0\240\0\0@\0\0\34\0\240\0\2\7\4\0+\0\240\0\0"..., 32}], 1) = 32 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN, revents=POLLIN}], 2, -1) = 1 read(7, "\17\3\215\n>\0\240\0\0028\254\277x3\22\n\3707\254\277T"..., 4096) = 64 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 0) = 0 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 0) = 0 select(8, [7], [7], NULL, NULL) = 1 (out [7]) writev(7, [{"\2\7\4\0A\0\240\0\0@\0\0\34\0\240\0\2\7\4\0+\0\240\0\0"..., 32}], 1) = 32 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN, revents=POLLIN}], 2, -1) = 1 read(7, "\17\0\217\n>\0\240\0\0008\254\277x3\22\n(8\254\277T\317"..., 4096) = 96 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 0) = 0 poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 0) = 0 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 0) = 0 select(8, [7], [7], NULL, NULL) = 1 (out [7]) writev(7, [{"5\30\4\0\23\3\240\0A\0\240\0\363\1T\1\233\4\5\0\24\3\240"..., 780}], 1) = 780 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}], 2, 0) = 0 select(8, [7], [7], NULL, NULL) = 1 (out [7]) writev(7, [{"\2\7\4\0A\0\240\0\0@\0\0\34\0\240\0\2\7\4\0+\0\240\0\0"..., 32}], 1) = 32 read(7, 0x85d1cd4, 4096) = -1 EAGAIN (Resource temporarily unavailable) Does anybody have the idea what going on? I use 1.8.2-0ubuntu1 version. ------------ Finally. I guess I posing a question that has been already asked 1000 times: Would it be very very difficult to implement an ODBC connector interface so many other databases such Oracle could be connected? Oracle has a really shit like admin console. It should be replaced if possible. Best regards, Levente -- Blogger of http://fapuma.blogspot.com Pictures of my life at http://picasaweb.google.com/TorokLev
On Mon, Mar 9, 2009 at 11:46 AM, Levente Torok <toroklev@gmail.com> wrote: > - One is what KDE control center does but I prefer the other one. > This is that: we have the original tree with all objects but once we enter something in the quick search window > the tree will be reduced to branches that appear under those objects that > contiain the entered search phrase in any fragment. > > -The KDE's approach is to generate a list of the items with partial matches. > > I prefer the former but may be more GUI space wasting than the latter one. I've not seen it, but the KDE approach sounds like what I'm favouring (which, I should point out has some significance on whether or not any particular patch will be accepted into pgAdmin). >> What do others think? > > > Really, what do others think??? > > > ---------------- > Question: > I cannot start up my pgadmin3. ... > Does anybody have the idea what going on? > I use 1.8.2-0ubuntu1 version. Not from that strace. Can you try the latest version? > > Finally. I guess I posing a question that has been already asked 1000 times: > Would it be very very difficult to implement an ODBC connector interface so > many other databases such Oracle could be connected? That should be possible, and I'd be happy to see it done. The biggest problem is likely to be that wxODBC isn't compiled into most builds of wxWidgets, and doesn't necessarily work well when it is. Quan is battling with this at the moment for his data import tool. The other issue to consider, is that anything we do with ODBC will be generic so it works with any DBMS - it may not be possible to do anything that is better than the Oracle UI with that restriction. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Since I'm not sure about the diff I just sent, here is a svn diff
Attachment
In case the diff didn't get these, and you need them.
Attachment
On Tue, Mar 10, 2009 at 3:18 AM, Chuck McDevitt <cmcdevitt@greenplum.com> wrote:
> Since I'm not sure about the diff I just sent, here is a svn diff
>
I've committed the revised patch, though I did need to make some
fairly extensive changes to get it into an acceptable state. I still
consider it to be fairly incomplete feature-wise, though it is an
improvement over the previous Greenplum support, and I think all the
nasty gotchas have now been cleaned up.
In the interests of preventing the same problems occuring again,
here's what I changed:
- Changes to hbaConfigFileFactory::StartDialog and
mainConfigFileFactory::StartDialog were removed. The changes made
changed the behaviour of them into hbaConfigFactory::StartDialog and
mainConfigFactory::StartDialog. The former are intended to open config
files from the local filesystem, the latter using pg_file_read() via a
connection to a server.
- I added a gpPartition::Refresh function so the treeview could
refresh properly in the even of a change to a partition object.
- Added code to gpResQueue::ShowTreeDetail to display the thresholds
and auto commit setting in the properties list for resource queues.
- Fixed the graphical explain to allow it to render a plan with nodes
with an average cost of zero. This doesn't happen in
PostgreSQL/EnterpriseDB (at least without some pretty funky
non-standard tuning parameters), but does on Greenplum with a brand
new empty table which caused an arrow to be rendered such that it
obscured the entire plan.
- Fixed dlgExtTable:
* When viewing an existing table, display the definition.
* Remove 'AS' from the generated SQL, which is not part of the
Greenplum syntax.
* Fix the ALTER TABLE ... SET OWNER statement (ALTER EXTERNAL
TABLE is not supported).
* Fix the dialogue so it doesn't think there has been a change to
the object when nothing has been modified.
* Fix the COMMENT ON statement (COMMENT ON EXTERNAL TABLE is not supported).
* Removed the useless Apply button.
- Disabled the default value textbox when viewing the properties of an
external table column.
- Removed a broken sub-collection of external tables form under an
external table node (copy 'n' paste error??)
- Prevented the addition of columns to external tables.
- Removed dlgPartition entirely. It was a 2000+ line copy of dlgTable,
with the buttons to add/remove columns removed!?!?! (that's completely
unacceptable from a maintenance perspective) This appears to have been
in response to my comments previously about removing or fixing the
options to add columns to partitions - however you seem to have fixed
those options if selected from the treeview, so currently they are
also available on dlgTable which is once again used for partitions.
- Added support for PDF helpfiles, which wasn't implemented per my
previous comments.
- Modfiied gpPartition::GetSql() to allow localisation of the note
about the DDL, and shorten said note.
I should note that I would normally have bounced this back for
reworking, particularly as some of these issues could have been picked
up with basic testing, however in this case I fixed it as I reviewed
in the interests of not delaying the beta.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
Dave, My apologies for making extra work for you. I've been trying to work on several different projects, all with deadlines happeningat nearly the same time, and am still learning the pgAdmin code, so things take me longer than they otherwise would. And our QA team is just getting ready to start testing my pgAdmin changes. > I've committed the revised patch, though I did need to make some > fairly extensive changes to get it into an acceptable state. I still > consider it to be fairly incomplete feature-wise, though it is an > improvement over the previous Greenplum support, and I think all the > nasty gotchas have now been cleaned up. Yes, it is very much not feature complete. We had our schedule set to have a first beta-ready version in about a month fromnow, not realizing the pgAdmin beta schedule. So this is somewhat of a rush job. > > In the interests of preventing the same problems occuring again, > here's what I changed: > > - Changes to hbaConfigFileFactory::StartDialog and > mainConfigFileFactory::StartDialog were removed. The changes made > changed the behaviour of them into hbaConfigFactory::StartDialog and > mainConfigFactory::StartDialog. The former are intended to open config > files from the local filesystem, the latter using pg_file_read() via a > connection to a server. Ok, how do I get the menu to use the latter versions when someone asked to open a config file? In the Greenplum DB case, there are no config files on the machine running pgAdmin. The config files are all on the server,which the user doesn't have access to except through libpq. > > - I added a gpPartition::Refresh function so the treeview could > refresh properly in the even of a change to a partition object. > Thanks... I hadn't put that in yet, since right now you can't change them, but had planned to do this before enabling changingthem. > - Added code to gpResQueue::ShowTreeDetail to display the thresholds > and auto commit setting in the properties list for resource queues. > > - Fixed the graphical explain to allow it to render a plan with nodes > with an average cost of zero. This doesn't happen in > PostgreSQL/EnterpriseDB (at least without some pretty funky > non-standard tuning parameters), but does on Greenplum with a brand > new empty table which caused an arrow to be rendered such that it > obscured the entire plan. Wow... I never thought to test this case! > > - Fixed dlgExtTable: > * When viewing an existing table, display the definition. > * Remove 'AS' from the generated SQL, which is not part of the > Greenplum syntax. > * Fix the ALTER TABLE ... SET OWNER statement (ALTER EXTERNAL > TABLE is not supported). > * Fix the dialogue so it doesn't think there has been a change to > the object when nothing has been modified. > * Fix the COMMENT ON statement (COMMENT ON EXTERNAL TABLE is not > supported). > * Removed the useless Apply button. > > - Disabled the default value textbox when viewing the properties of an > external table column. > > - Removed a broken sub-collection of external tables form under an > external table node (copy 'n' paste error??) > > - Prevented the addition of columns to external tables. > > - Removed dlgPartition entirely. It was a 2000+ line copy of dlgTable, > with the buttons to add/remove columns removed!?!?! (that's completely > unacceptable from a maintenance perspective) This appears to have been > in response to my comments previously about removing or fixing the > options to add columns to partitions - however you seem to have fixed > those options if selected from the treeview, so currently they are > also available on dlgTable which is once again used for partitions. Yes, dlgPartition was just a placeholder for the code to allow creating/modifying partitions. I was thinking it was better to get something that compiles and doesn't fail when run into those modules before the beta,because I was worried you wouldn't accept adding new files after the beta starts. As soon as I have time, I plan to implement working dlgPartition code to allow adding/changing partitions. > > - Added support for PDF helpfiles, which wasn't implemented per my > previous comments. > > - Modfiied gpPartition::GetSql() to allow localisation of the note > about the DDL, and shorten said note. > > I should note that I would normally have bounced this back for > reworking, particularly as some of these issues could have been picked > up with basic testing, however in this case I fixed it as I reviewed > in the interests of not delaying the beta. > > -- > Dave Page > EnterpriseDB UK: http://www.enterprisedb.com Yes, I understand. Like I said, I'm sorry for the extra work, and we will try to not have that happen in the future.
On Tue, Mar 10, 2009 at 7:56 PM, Chuck McDevitt <cmcdevitt@greenplum.com> wrote: > Yes, it is very much not feature complete. We had our schedule set to have a first beta-ready version in about a monthfrom now, not realizing the pgAdmin beta schedule. So this is somewhat of a rush job. I noticed :-). I have the same problem in EDB, though our first beta was a couple of weeks back. FYI, during the last cycle, the EDB version of pgAdmin was a little different from the community version, picking up a couple of features from the beginning of this development cycle. We maintained it as a private code branch, but did so in the project's main repository. I wouldn't necessarily recommend doing that if you can help it, however, *very* early in the next cycle we will be moving our development from Subversion to GIT, which will allow us much more flexibility in working with different branches for EDB & Greenplum etc. which can be maintained in their own release cycles and continually merged into the community branch. >> In the interests of preventing the same problems occuring again, >> here's what I changed: >> >> - Changes to hbaConfigFileFactory::StartDialog and >> mainConfigFileFactory::StartDialog were removed. The changes made >> changed the behaviour of them into hbaConfigFactory::StartDialog and >> mainConfigFactory::StartDialog. The former are intended to open config >> files from the local filesystem, the latter using pg_file_read() via a >> connection to a server. > > Ok, how do I get the menu to use the latter versions when someone asked to open a config file? > > In the Greenplum DB case, there are no config files on the machine running pgAdmin. The config files are all on the server,which the user doesn't have access to except through libpq. The options on the file menu always open files on the local server. To open server config files, use the options under Tools -> Server Configuration. >> >> - I added a gpPartition::Refresh function so the treeview could >> refresh properly in the even of a change to a partition object. >> > > Thanks... I hadn't put that in yet, since right now you can't change them, but had planned to do this before enabling changingthem. The problem is that you can change them, albeit as if they were tables. Although you copied dlgTable and disabled the add/change/remove columns buttons, you could still right-click columns in the treeview and modify them directly, or add news ones. Similarly, you can also change constraints and indexes etc. I *think*, that everything is now enabled (or disabled) consistently, and will work as expected, with the treeview refreshing as it should. Whether or not it makes sense to add a column to one partition is a whole other debate of course - but pgAdmin doesn't try to do anything that that you couldn't do through psql, so I'm happy nothing is technically broken. >> - Added code to gpResQueue::ShowTreeDetail to display the thresholds >> and auto commit setting in the properties list for resource queues. >> >> - Fixed the graphical explain to allow it to render a plan with nodes >> with an average cost of zero. This doesn't happen in >> PostgreSQL/EnterpriseDB (at least without some pretty funky >> non-standard tuning parameters), but does on Greenplum with a brand >> new empty table which caused an arrow to be rendered such that it >> obscured the entire plan. > > Wow... I never thought to test this case! :-). I was testing initially with empty tables lifted straight from the docs and ran into this one immediately. > Yes, dlgPartition was just a placeholder for the code to allow creating/modifying partitions. > I was thinking it was better to get something that compiles and doesn't fail when run into those modules before the beta,because I was worried you wouldn't accept adding new files after the beta starts. I won't, without a very compelling reason (though we can talk about a private code branch, as long as all code goes back into trunk eventually). We also don't keep placeholder code in release versions unless there is useful additional functionality there - we prefer to keep the release code as clean as possible. > As soon as I have time, I plan to implement working dlgPartition code to allow adding/changing partitions. Sound good. > Yes, I understand. Like I said, I'm sorry for the extra work, and we will try to not have that happen in the future. Thanks - appreciate it. I'm keen for us to continue to work together; it's worked well for EDB, improving the tools for our customers, and the community have benefited from additional developer and QA time in return. I hope we can work with Greenplum in a similar fashion. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dear Levente, Dave, List, here are patches with only the sample code of quick search. I did not attached any backtrace, because there are several points, where the program can suffer from segfault at my quick search, exactly operations with original Object browser. Please do a second search, don't finish at the first and you can see the error. Please take me a better solution for copying elements of original tree or how i can resolve this problem with GUI. I used these patches on the last repository. Sorry for the unfitted wxTextCtrl at new floating window, but at first i couldn't create it with ctlTree. Thank for your help! Regards, Marton Akos On Mon, Mar 9, 2009 at 10:38 AM, Dave Page <dpage@pgadmin.org> wrote: > On Sun, Mar 8, 2009 at 11:31 AM, Levente Torok <toroklev@gmail.com> wrote: > >> Look. The problem is the following. >> We have exteremely large number of items in the obj browser tree. >> In general, this is very unpleasant to manually search for items in the >> tree even if we know the exact name of it. For this reason we usually use >> psql console since it has mighty tab completion. >> If only such a quick filtering functionality would be integrated in the GUI, it would be extremely helpful. > > Except that, per my previous comments, it's like to be a lot more code > and less useful than a true search. > >> (not to mention the console integrated in the pgadmin) > > It can easily be in 1.10, using the plugins mechanism - in fact > integrating psql is our standard example. > >> I wouldn't like to do any click or key hit, if unneccessary and the synaptic's quick seach such as: >> http://www.basicconfig.com/files/imagepicker/j/jinlusuh/Screenshot-Synaptic%20quick%20search%20seamonkey.png >> are good examples of this but Compiz config, or KDE's control center are worth considering too. > > I understand what you are suggesting, but believe that in many cases > *more* clicks will be required. A search results listing can easily > show additional pertinent information about each matching object such > as it's type, owner and comment. With a filter, you can view the type > through the location on the tree, but that might require scrolling. > For information such as the owner or comment, you must locate and > click *every* object until you find the one you actually want. > > In addition, you could easily further refine a search results listing > by sort by different columns, or applying filtering to the results > list (for example, to only show objects owned by a certain user). That > is much harder to present in a UI in the design you propose. > > What do others think? > > -- > Dave Page > EnterpriseDB UK: http://www.enterprisedb.com > -- People seldom notice clothes, if you wear a big smile. OLVASD: http://napirajz.hu
Attachment
Hi Marton On Fri, Mar 13, 2009 at 4:04 AM, M@rton Akos <makos999@gmail.com> wrote: > Dear Levente, Dave, List, > > here are patches with only the sample code of quick search. Hmm, not sure what happened to the patch to frmMain.h - it looks like a diff between 2 modified versions of the file, rather than the original and new. I'd suggest just doing an 'svn diff' from the top level directory in future - that will create a single patch for all the changes. > I did not attached any backtrace, because there are several points, > where the program can suffer from segfault at my quick search, exactly > operations with original Object browser. Please do a second search, > don't finish at the first and you can see the error. > Please take me a better solution for copying elements of original tree > or how i can resolve this problem with GUI. > I used these patches on the last repository. > Sorry for the unfitted wxTextCtrl at new floating window, but at first > i couldn't create it with ctlTree. The only crash I could get in the debugger was if I searched for 'Dummy'. The treeview often has dummy nodes attached which the user never sees - these aren't linked to an object , so when you do this: currentObject=browser->GetObject(item); treee->AppendItem(treee->GetRootItem(), browser->GetItemText(item), currentObject->GetIconId(), -1, currentObject); you end up with currentObject == NULL which results in a crash. From what I can see in the patch, it looks like you're testing on Linux - I do the bulk of my debugging on Windows as the MSVC++ debugger makes it much easier. My guess is the different OS is the reason why you see a crash and I don't, however, I suspect it's happening because you're modifying currentObject which you should almost certainly not be touching. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
[Please keep messages on list] On Mon, Mar 16, 2009 at 2:49 AM, Akos Marton <makos999@gmail.com> wrote: > Hi Dave, > > Thanks your answer and advices! > I've done your corrections and the results didn't changed. I don't > understand what is the problem. Here's a backtrace for the example. I > am interested in the solution of this problem, or some advice, where > could I post any question to know the answer for this segfault - why > isn't it working on Linux and why is it working on Windows? -. > Until these answers I am working on another solution to dodge this. > Post your questions to the pgadmin-hackers mailing list - that's where we discuss this sort of thing. >> The only crash I could get in the debugger was if I searched for >> 'Dummy'. The treeview often has dummy nodes attached which the user >> never sees - these aren't linked to an object , so when you do this: >> currentObject=browser->GetObject(item); > > I removed the Dummies. OK >> treee->AppendItem(treee->GetRootItem(), browser->GetItemText(item), >> currentObject->GetIconId(), -1, currentObject); >> >> you end up with currentObject == NULL which results in a crash. >> >> From what I can see in the patch, it looks like you're testing on >> Linux - I do the bulk of my debugging on Windows as the MSVC++ >> debugger makes it much easier. My guess is the different OS is the >> reason why you see a crash and I don't, however, I suspect it's >> happening because you're modifying currentObject which you should >> almost certainly not be touching. > > I'm using another variable. OK. > It may couldn't help, but perhaps... > backtrace 1: http://pastebin.com/m2c1681e9 search for second times with my code > backtrace 2: http://pastebin.com/m3f5caa18 using another function in > pgadmin, after use my search What *exactly* are the steps your using to recreate the problem? The only thing that stands out in the back traces is in the second one: 0x08211e62 in frmMaintenance (this=0x91b1800, form=0x8cb8108, obj=0x0) at ./frm/frmMaintenance.cpp:54 The line it's crashing on (54) is trying to use the variable 'object' which is set to the value of 'obj' in in ExecutionDialog::ExecutionDialog. As you can see, that is null which is why it crashes. You need to traverse back up the stack and see where that value is coming from. Understanding how it gets set to null when it clearly should be a pointer to a valid object also requires understanding exactly what steps you follow to cause the problem in the first place. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Not sure if I got all the diff options right.