Обсуждение: pgadmin 1.8.0 beta3 bug
If there is a list of current bugs other than what appears in the help, please direct me to it. <br /><br />I'm using theWin32 version.<br /><br />1) When adding a new column to a table, I have hit "refresh" on the table before the columnis available within the add constraint dialog. <br /><br />Thanks,<br />Martin<br />
Martin Serrano wrote: > If there is a list of current bugs other than what appears in the help, > please direct me to it. > > I'm using the Win32 version. > > 1) When adding a new column to a table, I have hit "refresh" on the > table before the column is available within the add constraint dialog. Thanks Martin, I've committed a fix which should deal with this. Erwin; I'm somewhat wary of fixes in the treeview refresh code as there can be odd corner cases caused by the relationships between some object types. If I get you an updated exe, would you mind running it though it's paces to help check I didn't miss anything? Thanks, Dave.
Hi Dave! dpage@postgresql.org wrote: > (...) > > Erwin; I'm somewhat wary of fixes in the treeview refresh code as there > can be odd corner cases caused by the relationships between some object > types. If I get you an updated exe, would you mind running it though > it's paces to help check I didn't miss anything? Sure, I'll see what I can nag. :) Actually, I've had a posting on this very subject in my draft folder for some time. I was just not sure what's the best course of action to propose. I'll append it here, just in case. brandstetter@falter.at did not yet write: > Hi developers! Hi Dave! > > Testing the new snapshot: pgAdmin III 1.7.0 (Jun 22 2007, rev: > 6379:6385). Client Win XP, host: Debian Sarge / PG 8.1.8 > > When making changes to achild element of a table (column, index, ...) > in the properties dialog, the SQL pane for the object is being > refreshed immediately. However, the SQL pane for the table is not > refreshed at the same time. We end up with updated SQL for the child > element but obsolete SQL for the table. This is sort of confusing. > > I think it should be all or nothing in this case, with a preference on > "all": refresh the SQL pane for the table as well. > > Of course we have to take into account a manual refresh on a child > elements as well. If you have an easy way of checking whether the > refresh has brought anything new, you might cascade the refresh to the > table. We might end up with updated SQL for the table and for the > initiating child element, but obsolete SQL for other child elements. > > So the best course of action might be to refresh the SQL pane for > _all_ nodes of the table sub-tree whenever we "officially" know of a > change on any element in the tree under it - or on any element that > actually influences the SQL pane of the table. That is what is special > about the table node: it incorporates information of child objects in > the SQL pane. Other nodes don't. Except for views. (?) > > Or never refresh anything unless the user explicitely requests it. A > refresh _may_ also be unwelcome, as information may be lost! I have > used the old information to undo changes that went wrong before ... > > As far as I have seen, v1.6.3 behaves the same way. > > I AM JUST NOT SURE. Regards Erwin
Erwin Brandstetter wrote: > Hi Dave! > > dpage@postgresql.org wrote: >> (...) >> Erwin; I'm somewhat wary of fixes in the treeview refresh code as there >> can be odd corner cases caused by the relationships between some object >> types. If I get you an updated exe, would you mind running it though >> it's paces to help check I didn't miss anything? > > Sure, I'll see what I can nag. :) Thanks! http://developer.pgadmin.org/~dpage/pgadmin3.zip > Actually, I've had a posting on this very subject in my draft folder for > some time. I was just not sure what's the best course of action to propose. > I'll append it here, just in case. I've changed the behaviour somewhat so that's probably a little out of date. There are undoubtedly some corner cases which would be a nightmare to catch, but let's see if you pick anything up first. Thanks, Dave
Hi Dave! dpage@postgresql.org wrote: (...) > I've changed the behaviour somewhat so that's probably a little out of > date. There are undoubtedly some corner cases which would be a nightmare > to catch, but let's see if you pick anything up first. > I am back on my feet again and have run a few tests with the new Windows pgAdmin3.exe. All the issues I had brought up since beta3 seem to be fixed. (As you said, the mouse pointer is still a little hyperactive when clicking on a server node. But it's much better than before.) Concerning the issue at hand I am unsure what to look for. What Martin addressed in his initial posting seems fixed in any case. Other things might remain to be addressed. For instance: add a new field per dialog.-> field shows up in "Columns" tree and also in "New Object .." dialogs-> SQL panefor table still displays obsolete SQL, however To test whether it works, we need to be clear about how exactly it should work. Would be talking on IRC be helpful? LG Erwin
Erwin Brandstetter wrote: > Hi Dave! > > dpage@postgresql.org wrote: > (...) >> I've changed the behaviour somewhat so that's probably a little out of >> date. There are undoubtedly some corner cases which would be a nightmare >> to catch, but let's see if you pick anything up first. >> > > I am back on my feet again and have run a few tests with the new Windows > pgAdmin3.exe. All the issues I had brought up since beta3 seem to be > fixed. (As you said, the mouse pointer is still a little hyperactive > when clicking on a server node. But it's much better than before.) > > Concerning the issue at hand I am unsure what to look for. What Martin > addressed in his initial posting seems fixed in any case. Other things > might remain to be addressed. > For instance: add a new field per dialog. > -> field shows up in "Columns" tree and also in "New Object .." dialogs > -> SQL pane for table still displays obsolete SQL, however OK, I've applied a fix for that. > To test whether it works, we need to be clear about how exactly it > should work. Would be talking on IRC be helpful? I try to avoid IRC generally as it's too distracting for little gain. I'm usually on MS Messenger as dpage@postgresql.org though, or (slightly less often) on Yahoo as pgSnake. I think in this case though we should generally get a refresh whenever anything in a sub node changes anything in a parent or grandparent node. I think I've largely nailed this for tables now (which is pretty much the only place it happens that I can think of), the only downside being that it causes the child collection nodes to get recreated which causes them to become collapsed. Not sure how to fix that without a fairly large rewrite. Regards, Dave
dpage@postgresql.org wrote: > Erwin Brandstetter wrote: > >> (...) >> Concerning the issue at hand I am unsure what to look for. What Martin >> addressed in his initial posting seems fixed in any case. Other things >> might remain to be addressed. >> For instance: add a new field per dialog. >> -> field shows up in "Columns" tree and also in "New Object .." dialogs >> -> SQL pane for table still displays obsolete SQL, however >> > > OK, I've applied a fix for that. > > >> To test whether it works, we need to be clear about how exactly it >> should work. Would be talking on IRC be helpful? >> > > I try to avoid IRC generally as it's too distracting for little gain. > I'm usually on MS Messenger as dpage@postgresql.org though, or (slightly > less often) on Yahoo as pgSnake. > > I think in this case though we should generally get a refresh whenever > anything in a sub node changes anything in a parent or grandparent node. > ... AND we officially know it. You cannot catch the changes applied via SQL. Also, there is always the possibility that someone else has made changes in the background. So, to be reasonably sure to be up to date, you would still have to refresh manually. > I think I've largely nailed this for tables now (which is pretty much > the only place it happens that I can think of), Also applies to views. (column defaults ...) > the only downside being > that it causes the child collection nodes to get recreated which causes > them to become collapsed. Not sure how to fix that without a fairly > large rewrite. > If any change via properties dialog would collapse the whole table subtree that would be a change for the worse IMO. Then I'd rather have the status quo ante. Is there no way to just refresh the SQL pane? Regards Erwin
Erwin Brandstetter wrote: > Also applies to views. (column defaults ...) It works for them as well. >> the only downside being >> that it causes the child collection nodes to get recreated which causes >> them to become collapsed. Not sure how to fix that without a fairly >> large rewrite. >> > > If any change via properties dialog would collapse the whole table > subtree that would be a change for the worse IMO. Then I'd rather have > the status quo ante. > Is there no way to just refresh the SQL pane? Not really - it's generated from all the other bits of data. I updated the .exe at http://developer.pgadmin.org/~dpage/pgadmin3.zip; try it out and see what you think. /D
dpage@postgresql.org wrote: > Erwin Brandstetter wrote: > >> If any change via properties dialog would collapse the whole table >> subtree that would be a change for the worse IMO. Then I'd rather have >> the status quo ante. >> Is there no way to just refresh the SQL pane? >> > > Not really - it's generated from all the other bits of data. I updated > the .exe at http://developer.pgadmin.org/~dpage/pgadmin3.zip; try it out > and see what you think. > Thanks, got it and tested it. Having the whole table subtree collapse with any adjustment kills the workflow. If, for instance, I want to add /change comments for a dozen fields of a table this quickly becomes a pain. I see the SQL pane being out of date as the lesser pain under the given circumstances. It also has advantages:- The SQL pane can serve as a "backup" if you mess up. You can restore the previous state from there.- It teaches you to refresh the SQL pane before you work on it - which is always a good idea.- Less traffic /load on the database If there was a cheaper way to cascade changes to SQL pane, I would probably go for it. If there isn't, how about this: add a timestamp to the header. Like this: -- Table: foo (snapshot created: 2007-08-27 17:24:17) -- DROP TABLE foo; CREATE TABLE foo .... Regards Erwin
Erwin Brandstetter wrote: > dpage@postgresql.org wrote: >> Erwin Brandstetter wrote: >> >>> If any change via properties dialog would collapse the whole table >>> subtree that would be a change for the worse IMO. Then I'd rather have >>> the status quo ante. >>> Is there no way to just refresh the SQL pane? >>> >> >> Not really - it's generated from all the other bits of data. I updated >> the .exe at http://developer.pgadmin.org/~dpage/pgadmin3.zip; try it out >> and see what you think. >> > > Thanks, got it and tested it. > Having the whole table subtree collapse with any adjustment kills the > workflow. If, for instance, I want to add /change comments for a dozen > fields of a table this quickly becomes a pain. OK, I figured out how to hierarchically retain the expanded/collapsed state of the child nodes during refresh - turned out to be *much* easier that I thought it would be. I've updated the .exe again - please let me know what you think. /D
On 29/08/2007 11:43, Dave Page wrote: > OK, I figured out how to hierarchically retain the expanded/collapsed > state of the child nodes during refresh - turned out to be *much* easier > that I thought it would be. I'm delighted that's been sorted - a small niggle, but one which has caught me once or twice. Good on you! > I've updated the .exe again - please let me know what you think. I've zapped the email with the link - any chance you could post it again? Ta..... Ray. --------------------------------------------------------------- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland rod@iol.ie ---------------------------------------------------------------
Raymond O'Donnell wrote: > On 29/08/2007 11:43, Dave Page wrote: > >> OK, I figured out how to hierarchically retain the expanded/collapsed >> state of the child nodes during refresh - turned out to be *much* easier >> that I thought it would be. > > I'm delighted that's been sorted - a small niggle, but one which has > caught me once or twice. Good on you! Thanks :-). >> I've updated the .exe again - please let me know what you think. > > I've zapped the email with the link - any chance you could post it > again? Ta..... http://developer.pgadmin.org/~dpage/pgadmin3.zip /D
dpage@postgresql.org wrote: > OK, I figured out how to hierarchically retain the expanded/collapsed > state of the child nodes during refresh - turned out to be *much* easier > that I thought it would be. > > I've updated the .exe again - please let me know what you think. > Very good! But some things are not right .. Testing Beta 3.5(Aug 29 2007, rev: 6584:6588M) on Win XP. Client Win XP, host: Debian Etch / PG 8.2.4 and Debian Sarge / PG 8.1.8. Everything concerns the table subtree. - Generally: either the focus jumps to the table node OR the table node is not updated. We want the focus to stay with (or go back to) the object we are working on, while (after) the table node is updated. Objects that do not update the table node: - primary key constraint - check constraint Objects that update the table node, but lose the focus: - foreign key constraint - unique constraint - table column - Trying to add a comment to UNIQUE CONSTRAINT fails altogether. - ALL comments on constraints or indexes are missing in the reverse engineered SQL for the table. To be precise, they are present as comments, but the SQL statements to recreate them are missing: COMMENT ON CONSTRAINT test_pkey ON loc_status IS 'My commenton this field...'; - When creating a new FOREIGN KEY CONSTRAINT per dialog (I do these things with SQL normally) "New Object -> New Foreign Key .." I cannot enter a comment. It won't let me write in the field. I can add comments to existing constraint of the kind, though. Thefield "Tablespace" seems to do nothing at all. Choosing a different tablespace does not activate the OK button. IF I activate the OK button with other changes and save, the tablespace setting is ignored. - SQL pane of the table is NOT updated. Onlyafter a manual refresh does the new foreign key show up. - There is a checkbox "Auto FK index" among the properties for FOREIGN KEY CONSTRAINTs. But I cannot find an explanation what it does anywhere. I guessed it creates an index on the referencing field. When I check the box and save, nothing seems to happen. The additional index is still created as expected, but the index collection is not refreshed. Only after manual refresh does the new index show up. - Trying to update a TRIGGER fails altogether. It tries to send SQL in the form: CREATE OR REPLACE TRIGGER mytrigger AFTER INSERT ... But there is no "CREATE OR REPLACE" for triggers. http://www.postgresql.org/docs/current/static/sql-createtrigger.html Regards Erwin
Erwin Brandstetter wrote: > > - Trying to add a comment to UNIQUE CONSTRAINT fails altogether. Actually, it doesn't fail to write. It just doesn't show up anywhere in pgadmin afterwards. psql doesn't seem to have a meta-command to retrieve comments on constraints. But checking by OID with "obj_description" reveals it: SELECT obj_description(2666870, 'pg_constraint'); Regards Erwin
Erwin Brandstetter wrote: > Very good! But some things are not right .. Gah!! > Testing Beta 3.5(Aug 29 2007, rev: 6584:6588M) on Win XP. Client Win XP, > host: Debian Etch / PG 8.2.4 and Debian Sarge / PG 8.1.8. > Everything concerns the table subtree. > > > - Generally: either the focus jumps to the table node OR the table node > is not updated. > We want the focus to stay with (or go back to) the object we are > working on, while (after) the table node is updated. > > Objects that do not update the table node: > - primary key constraint > - check constraint Those should now be fixed (and consequently behave like the others below). > Objects that update the table node, but lose the focus: > - foreign key constraint > - unique constraint > - table column I'm not sure how to fix this - I'll think about it this afternoon. > - Trying to add a comment to UNIQUE CONSTRAINT fails altogether. Fixed. > - ALL comments on constraints or indexes are missing in the reverse > engineered SQL for the table. To be precise, they are present as > comments, but the SQL statements to recreate them are missing: > COMMENT ON CONSTRAINT test_pkey ON loc_status IS 'My comment on this > field...'; Fixed. > - When creating a new FOREIGN KEY CONSTRAINT per dialog (I do these > things with SQL normally) "New Object -> New Foreign Key .." I cannot > enter a comment. It won't let me write in the field. Some backwards logic - it would if there was no name specified. It should (and now is) the other way round - that is, if you've named the constraint, you can give it a comment. > I can add comments to existing constraint of the kind, though. > The field "Tablespace" seems to do nothing at all. Choosing a > different tablespace does not activate the OK button. IF I activate the > OK button with other changes and save, the tablespace setting is ignored. Err, what Tablespace field? > - SQL pane of the table is NOT updated. Only after a manual refresh > does the new foreign key show up. Seems to be OK here - possibly as a side effect of one of the other fixes. > - There is a checkbox "Auto FK index" among the properties for FOREIGN > KEY CONSTRAINTs. > But I cannot find an explanation what it does anywhere. I guessed it > creates an index on the referencing field. Yes. > When I check the box and save, nothing seems to happen. The > additional index is still created as expected, but the index collection > is not refreshed. Only after manual refresh does the new index show up. Seems to be OK here - possibly as a side effect of one of the other fixes. > > - Trying to update a TRIGGER fails altogether. It tries to send SQL in > the form: > CREATE OR REPLACE TRIGGER mytrigger AFTER INSERT ... > But there is no "CREATE OR REPLACE" for triggers. > http://www.postgresql.org/docs/current/static/sql-createtrigger.html Ahh, thats an EDB thing. Fixed. Thanks, Dave
Hi Dave! Sounds like you've nailed issues with the big nail gun this morning. :) Looking forward to the next version. dpage@postgresql.org wrote: (...) > Erwin Brandstetter wrote: > >> The field "Tablespace" seems to do nothing at all. Choosing a >> different tablespace does not activate the OK button. IF I activate the >> OK button with other changes and save, the tablespace setting is ignored. >> > > Err, what Tablespace field? > The tablespace issue concerns primary key - and unique constraints. This should have gone into a separate paragraph but got mixed up. Regards Erwin
Erwin Brandstetter wrote: > The tablespace issue concerns primary key - and unique constraints. > This should have gone into a separate paragraph but got mixed up. I have had another look at this. On Indexes, the field "Tablespace" is generally deactivated (with pg 8.1 or 8.2). I do have an additional tablespace to choose from in my test db-clusters and I can change the tablespace for indexes per SQL. ALTER INDEX test_idx SET TABLESPACE my_tblspace; It should only be deactivated for pg < 8.0, as it is was introduced in pg 8.0. Maybe the feature to move indexes around is not ready yet, but you forgot to deactivate it for constraints implementing an index : primary key / unique constraints. So if I got it right, we should either implement / activate the feature for pg 8.0+ (and activate the corresponding field in index properties) or deactivate the field for those constraints, too. Regards Erwin