Thread: Slony scripts

Slony scripts

From
"Dave Page"
Date:
Hi Andreas

I was thinking about including the Slony scripts with the
pgAdmin/pgInstaller packaging. To save me rooting through the code to
find it, where does we look for them at the moment? Also, how do we
handle different Slony versions? Scripts in a subdirectory someplace, or
do we rename them so they don't clash. Or do we say you can only create
clusters in the version that you have installed the scripts for?

Cheers, Dave.

Re: Slony scripts

From
Andreas Pflug
Date:
Dave Page wrote:

>Hi Andreas
>
>I was thinking about including the Slony scripts with the
>pgAdmin/pgInstaller packaging. To save me rooting through the code to
>find it, where does we look for them at the moment? Also, how do we
>handle different Slony versions? Scripts in a subdirectory someplace, or
>do we rename them so they don't clash. Or do we say you can only create
>clusters in the version that you have installed the scripts for?
>
>

See slony path in options.
We don't maintain different versions, but assume that we're always using
the latest. When joining a cluster or upgrading a cluster (not the
first), all ddl info is extracted from existing clusters, so no scripts
are needed.
dlgRepClusterUpgrade implementation still to be coded; dlgRepCluster
schema reengineering code needs to be extracted to a standalone class.
It's also needed for initial schema creation as duplicate from an
existing source db, e.g. for new replication slaves. Should be a context
menu option opening the Query Tool with the ddl script for review.

Regards,
Andreas


Re: Slony scripts

From
"Dave Page"
Date:

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 19 September 2005 15:39
> To: Dave Page
> Cc: pgAdmin Hackers
> Subject: Re: Slony scripts
>
> See slony path in options.

OK - needs a helpfile update ethough :-p

> We don't maintain different versions, but assume that we're
> always using
> the latest. When joining a cluster or upgrading a cluster (not the
> first), all ddl info is extracted from existing clusters, so
> no scripts
> are needed.
> dlgRepClusterUpgrade implementation still to be coded; dlgRepCluster
> schema reengineering code needs to be extracted to a
> standalone class.
> It's also needed for initial schema creation as duplicate from an
> existing source db, e.g. for new replication slaves. Should
> be a context
> menu option opening the Query Tool with the ddl script for review.

OK, well I won't bother shipping any Slony scripts at all with pgAdmin
then, and I'll only add them top pgInstaller when Slony for Windows
ships - that way it's up to the admin to ensure he has the correct
scripts for the installed version, except in the case when they all come
from the same place.

Cheers, Dave.

Re: Slony scripts

From
Andreas Pflug
Date:
Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
>>Sent: 19 September 2005 15:39
>>To: Dave Page
>>Cc: pgAdmin Hackers
>>Subject: Re: Slony scripts
>>
>>See slony path in options.
>
>
> OK - needs a helpfile update ethough :-p
>
>
>>We don't maintain different versions, but assume that we're
>>always using
>>the latest. When joining a cluster or upgrading a cluster (not the
>>first), all ddl info is extracted from existing clusters, so
>>no scripts
>>are needed.
>>dlgRepClusterUpgrade implementation still to be coded; dlgRepCluster
>>schema reengineering code needs to be extracted to a
>>standalone class.
>>It's also needed for initial schema creation as duplicate from an
>>existing source db, e.g. for new replication slaves. Should
>>be a context
>>menu option opening the Query Tool with the ddl script for review.
>
>
> OK, well I won't bother shipping any Slony scripts at all with pgAdmin
> then, and I'll only add them top pgInstaller when Slony for Windows
> ships -


  that way it's up to the admin to ensure he has the correct
> scripts for the installed version, except in the case when they all come
> from the same place.

Yup. Could be written to HKLM/Software/pgAdmin III /SlonyPath, and read
from there as default if HKCU/Software/pgAdmin III /SlonyPath is not set.

Regards,
Andreas