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
<davi...@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.
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
