Re: Missing "New Node"

Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
>>Sent: 09 June 2005 11:33
>>To: Dave Page
>>Cc: Christopher Kings-Lynne; pgadmin-hackers
>>Subject: Re: Missing "New Node"
>>
>>
>>Hm, let me think what I might have been thinking those days.
>>
>>1) Set/Subscription
>>Generally, new <object> on a <object> collection should be
>>possible as
>>well as <new same obj> on a <object>. If that's missing,
>>something's wrong.
>>In this case, things might be screwed up, because adding
>>subscriptions
>>are only possible on sets that are not owned by the current
>>node, while
>>maintaining sets is only possible on the owning node.
>>Currently, own and
>>foreign sets/replications (viewed from the current node) aren't
>>distinguishable, so we probably should add icons to differentiate.
>

I just quick'n'dirty added some new icons to distinguish own and foreign
sets/subscriptions. This should be refactored some day, to use different
classes.

>
> Sounds reasonable - something definitely ain't right though. For
> example, using the databases created by Slony's test_1_pgbench test, if
> I browse the slony_test1 database (the origin), and go to
> Replication/T1/Replication Sets/Set 1 - pgbench tables, I can
> right-click and select New Object->Add [Table|Sequence]. However, if I
> right-click the child sequences or Tables collection nodes, I only get
> the Refresh option. Istm that I should get Add Sequence/Add Table on
> those.

Agreed.

>
> The same applies to the Subscriptions node on the slony_test2 database -
> there is no Add Subscription option. There is one on the Set node (as
> there is for Tables/Sequences on the origin), however this throws an
> exception when selected.

This can't possibly be a bug, no? ;-)
>
>
>>2) Nodes
>>IIRC In the beginning I explicitely didn't allow "New Node" because a
>>new replication node is created implicitely when a db is joined to a
>>cluster.
>>
>>But:
>>With pgAdmin, there's a new "administrative node", which
>>holds paths to
>>the replication nodes being maintained. There should be code
>>in "create
>>cluster" and "Join Cluster" to create the administrative node as well.
>
>
> I'd kindof assumed that the 'administrative' node was the origin node.
>
>
>>pgAdmin needs access to all replication node servers, and
>>thus needs to
>>store the connection info somewhere as well. This is done
>>regarding the
>>pgAdmin machine (and all machines with similar connectivity) as
>>"administrative node", and the conn info is stored in the sl_path the
>>usual way. The sl_node itself won't tell the difference,
>>there's just no
>>slon process running on it but a pgadmin (or phppgadmin :-).
>
>
> So how does this work with slonik created clusters (such as I have)? Is
> this why I seem to be unable to join existing clusters (the server and
> other combos are all blank, even with other nodes running on the local
> machine).

Bug, fixed in svn. All registered servers should appear.

It might be necessary to add the admin node for your machine, as well as
paths to the nodes.

Regards,
Andreas