Skip site navigation (1) Skip section navigation (2)

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

From: Dave Page <dpage(at)pgadmin(dot)org>
To: David Vaillancourt <david_v(at)sympatico(dot)ca>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Fwd: PGadmin Schema/DDL VCS plugin ...
Date: 2011-12-15 16:31:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On Thu, Dec 15, 2011 at 4:18 PM, David Vaillancourt
<david_v(at)sympatico(dot)ca> wrote:
> 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.

That's fine with me, assuming the changes you wish to make will fit
into that model cleanly.

> 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?

The same way as any of the other code in the repo. When a developers
work is finished, reviewed and then committed, the guys working in
parallel will just do a pull and rebase their work over the latest
changes. That may not be practical with hundreds of developers, but
there typically aren't more than 7 or 8 developers at most working on
this project, so there's little coordination required beyond git

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

Manually. If they've added some new columns to a table the upgrade
script will contain ALTER TABLE statements, whilst the CREATE TABLE
statements in pemserver.sql will get the additional columns added. On
a couple of occasions (for example, when updating 237 SQL objects we
call probes) that gets a touch tedious, but the vast majority of the
time it's a non-issue.

> * 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)

Typically developer A will just do a "git pull". If there are merge
conflicts then he may need to do a "git stash" first, and then "git
stash apply" to re-apply his changes, fixing any conflicts manually.
If he's already committed to his local repo, git detects the conflicts
and A can manually fixup them up and commit the result, then push it
back to the central repo when he's done.

Dave Page
Twitter: @pgsnake

EnterpriseDB UK:
The Enterprise PostgreSQL Company

In response to

pgadmin-hackers by date

Next:From: Dhiraj ChawlaDate: 2011-12-16 13:19:44
Subject: Adding a "New Folder" button to Add Favourites dialog in Query Tool
Previous:From: David VaillancourtDate: 2011-12-15 16:18:31
Subject: Re: Fwd: PGadmin Schema/DDL VCS plugin ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group