Re: Fwd: PGadmin Schema/DDL VCS plugin ...

The changes to the plugin framework I intend to implement would keep the
existing functionality, but add to it also.
Please let me know if this is an avenue I should drop, as I will find an
alternative ... It do not want to work against the PGadmin team.

As for the workflow you describe to track Schema versions, this is the
way we do things right now.
So here are my questions:

* How do you manage incremental scripts numbering for multiple
developers working on the same DB Schema?

* Once a developer creates an incremental script, who/how do you modify
the original creating script to reflect these new changes (ex:
pemserver.sql)?

* If developer A has pending modifications but another developer B has
commited changes to the schema since, how does developer A make sure he
is not going to overwrite changes made by A? This especially problematic
for stored procedures code that is modified by developers (for us anyways)

I am genuinely interested by your answers, since it may well be that we
adopt your workflow if it improves ours.


Cheers!


On 15/12/2011 10:43 AM, Dave Page wrote:
> On Thu, Dec 15, 2011 at 3:36 PM, David Vaillancourt
> <david_v@sympatico.ca>  wrote:
>> Dave,
>>
>> Thanks for the quick feedback. I'm really surprised that people who use VCS
>> for their 'normal' code, wouldn't see a use for the same when it comes to DB
>> Schema/DDL versions.
>> In any case, my goal is not to add the functionality directly to PGAdmin,
>> but rather create a plugin for PGadmin to use.
> Yeah, the current plugin architecture really isn't suited to that I
> doubt - its pretty simplistic. I certainly have objections to that
> being enhanced though.
>
>> As I mentionned earlier, the extent of the modifications to PGadmin would be
>> to extend the plugin framework to allow a tighter coupling between plugins
>> and PGadmin.
>> I guess maintaining a plugin is different from maintaining yet another
>> feature in the existing PGAdmin code, correct me if i'm wrong.
> Currently a "plugin" is really just an external application that
> pgAdmin can fire up and pass command line options to.
>
>> Finally, since no one wanted to use the VCS feature in PGadmin, what do
>> teams of developers use to track versions of Schemas (Tables, Views,
>> Procedures...)?
>> Do most developers simply not use any? Or do the 'hack' their own? I'd be
>> surprised if they used proprietary tools ...
> Well, views may have changed now - the original code was probably
> written nearly 10 years ago. However, the PostgreSQL infrastructure
> team just tend to keep SQL scripts in GIT and update them when
> necessary. For the Postgres Enterprise Manager product that I work on
> in my day job (which happens to be based on pgAdmin), we maintain one
> script which creates a fresh database from scratch (pemserver.sql),
> and incremental scripts to upgrade an existing database from one
> version to another (eg. 2_0_0-2_0_1.sql, 2_0_1-2_0_2.sql and so one).
> All of those are version controlled in GIT as well.
>