Re: pgadmin 1.8.0 beta3 bug

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