Re: Support for Slony 2.0?

On 20 January 2011 21:28, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> A wizard as you suggest has been on my "if only i had the time and
> energy" todo list for a few years :-)

It's something that I'd like to take a look at, once we finish wx 2.9
support. As I think you'll agree, it's important that the end result
is a Slonik script rather than a series of calls to bare metal
functions from within PgAdmin. It's useful to produce something that
people can generalise from, keep and append (if only with comments).
We shouldn't attempt to completely abstract away the details, because
that probably isn't going to work. I think that this approach will
bring most of the benefits of command line tools, without the same
degree of complexity. There's obviously a lot of redundancy within
Slonik scripts, where each connection string must appear multiple
times and so on. Slonik is a bit of a foot-gun. It was designed to be
embedded within other languages for a reason I suppose. Its
flexibility and extensibility is more of a hindrance than a help to
many users, at least when there isn't some tool that makes it
accessible.

I think that users are inclined to add nodes and their paths a node at
a time, perhaps in some logical domain specific order. As things
stand, the user has to navigate the entire set of nodes with the
object browser and add listens/paths everywhere when adding each new
node. On the other hand, when writing a slonik script, most people
will just add nodes one after the other, and append the paths that
relate to the node that they are currently storing paths for, without
much regard to what node each path will actually reside on. I like to
put each node's "store path()"s within a separate, commented block. I
also like to order the store path()s within that commented block
logically and consistently.

I think that the wizard (a term that I'm not fond of, because it's
sort of reminiscent of Microsoft Bob or something) should first
present the user with the option of generating a script that does a
handful of high level things - the single well defined tasks that most
Slonik scripts do, such as creating a new cluster while creating a new
replication set, adding/removing a new node to/from an existing one or
executing a script. I'm pretty sure that it'll be possible to do all
of this without storing any additional metadata.

--
Regards,
Peter Geoghegan