Re: More refresh issues

Erwin Brandstetter wrote:
> - After deleting an object in the table subtree, the focus jumps back to
> the table node. Ideally, the focus would go to the the nearest brother
> object or father node.

OK, now jumps to the parent.

> - After creating a new object, the focus would end up on the new object
> in an ideal world.

No straightforward way to change that as far as I can see. No-one has
ever complained though so I'm not going to bust a gut to change that.

> - When refreshing the database collection, all databases except the
> maintainance db are closed, and the trees collapsed. Is this necessary
> for some reason?

The way the code is currently architected, refreshing a database will
not re-open its connection. Again, I'm not going to worry about that now
as it's always been that way (yes, it's slightly inconsistent with other
refreshes, but then it's obvious that that node is different anyway).

> - The tree is a bit hyperactive at times (going up / down, blanking
> out), before it settles after changes - especially after deleting
> objects. That's really a small thing, though.

In some situations we were refreshing the node and it's parent
collection, and then the grandparent. I've changed it so that if we're
going to refresh the grandparent, we don't bother explicitly doing the
children/grandchildren first.

> - Dropping constraints by pressing <DEL> fails, because the dot between
> schema and table name is missing in the executed SQL (SQL pane is
> correct, though!):
> ALTER TABLE myschemamytable DROP CONSTRAINT xxx;
> Should be:
> ALTER TABLE myschema.mytable DROP CONSTRAINT xxx;
> Affects check and foreign key constraints.

Fixed.

> - Creating a constraint per dialog offers a checkbox "Deferrable". This,
> however, is only applicable for foreign key constraints. With all other
> types it produces a syntax error if you use it:
> ALTER TABLE cpflat.cpkat ADD CONSTRAINT xxx UNIQUE (nummer, katcode)
> DEFERRABLE INITIALLY IMMEDIATE;
> http://www.postgresql.org/docs/8.2/interactive/sql-createtable.html says:
>>
>> DEFERRABLE
>> (...) Only foreign key constraints currently accept this clause. All
>> other constraint types are not deferrable.

Wierd. Wonder why they were included. Oh well, removed now.

> - More refresh issues:
> - After renaming a SEQUENCE, connected tables are out of date.

I think that'll have to stay as it is for now. Refreshing all the tables
in the database (because it might affect tables in more than one schema
of course) could be *extremely* expensive. I've seen extreme cases where
it could take a minute or more to build a tables tree as it is :-(

> - After renaming a TABLESPACE, all indexes, tables, databases, primary
> key and unique constraints using are out of date.
> This actually can have severe side effects. After renaming a
> tablespace, the combobox "Tablespace" in the properties dialog already
> uses the new name, but the table still has the old one, so the display
> defaults to "pg_default". If you use the properties dialog to do
> anything in such a situation, the table is silently moved to
> "pg_default". Evil, evil.
> Maybe it would be a good strategy to perform a refresh on objects right
> before opening the properties dialog? This would certainly take care of
> the above situation.
> I think we have identified most things now, but there may be more. This
> is a bit of a can of worms. :(

I was able to modify things here to track each object's tablespace by
OID rather than name. It's still possible to rename a tablespace under
an open properties dialogue which results in an error, but that applies
to all sorts of other things as well. In any case, it's predictable and
well behaved now.

> - A related case:
> When you refresh any part of the tree manually, changes may turn up,
> while other objects, which are also affected, keep their obsolete status.
> If you have a way to probe for changes, this might be easy to catch.
> Otherwise it may be tricky / expensive. For instance ..
> .. if you refresh the sequence collection, in theory, you would have
> to refresh all table objects connected with a sequence.
> .. if you refresh any part of the table subtree, you would always have
> to refresh the table as well. (This should be easy, actually.)
> .. if you refresh the Trigger Functions collections -> all tables with
> triggers.
> .. more cases
> This is an even bigger can of worms. It is probably better to just leave
> it to the user and not try to cascade manual refreshes.

I'm not convinced there's any sensible way of fixing these issue unless
we switch to a 'refresh-on-select' type design. That would actually
allow us to get rid of a fair bit of the code I've written over the last
few days I imagine, but would be far less bandwidth friendly.

Anyhoo, thanks for the bug reports; very precise as usual. We're
starting to run short on time now so I'm going to call a halt to all
further behavioural fixes for this release *except* for blatant errors
or regressions.

Usual update for testing is at
http://developer.pgadmin.org/~dpage/pgadmin3.zip. Please note that this
was built on my home PC which has a slightly different environment than
my normal machine. IF you get any dependency errors, let me know and
I'll whip the laptop out.

/D