Обсуждение: How do I connect postgres table structures and view structures to an existing svn repository?

Hi,<br /><br />How do I connect postgres table structures and view structures to an existing svn repository?<br /><br
/>Thanks,<brclear="all" /><br />-- <br />John J. Mitchell  

I am trying to store schema definitions in version-control which I can do by saving the definition and then  importing  into svn, but I  would like  it to be automatic , so that when an update occurs to a table or view within postgres then that table or view is flagged within svn.  This would be similar to what I currently do with source code that I have for a web app within  eclipse.




--
John J. Mitchell

On Wed, 1 Aug 2007 10:07:31 -0400
"John Mitchell" <mitchelljj98@gmail.com> wrote:
> How do I connect postgres table structures and view structures to an
> existing svn repository?

I'm not sure that I understand the connection between SQL and SVN.  Can
you be a bit clearer about what you are trying to do?  

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Wed, 1 Aug 2007 11:45:21 -0400
"John Mitchell" <mitchelljj98@gmail.com> wrote:
> I am trying to store schema definitions in version-control which I can do by
> saving the definition and then  importing  into svn, but I  would like  it
> to be automatic , so that when an update occurs to a table or view within
> postgres then that table or view is flagged within svn.  This would be
> similar to what I currently do with source code that I have for a web app
> within  eclipse.

Not really an SQL question, in fact it is barely a PostgreSQL question
at all but I will try to give a pointer.

I don't know of any automated tools.  I would suggest running a
cron script that dumps the database and then does an svn commit.  If
there are no changes then the commit will do nothing.  If there are
changes then svn will be updated.

Don't forget to pipe a log message into svn (-F or --file option) and
you may need to check for irrelevant changes in the dump before calling
svn.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On 8/1/07, John Mitchell <mitchelljj98@gmail.com> wrote:
> I am trying to store schema definitions in version-control which I can do by
> saving the definition and then  importing  into svn, but I  would like  it
> to be automatic , so that when an update occurs to a table or view within
> postgres then that table or view is flagged within svn.  This would be
> similar to what I currently do with source code that I have for a web app
> within  eclipse.

OK, the first decision point is whether you want to store whole
schemas and blow away the old one each time, or if you want to store
incremental changes.

I recommend creating an initial schema of version 1.0, and then
creating delta files after that as you change your schema.

Your first schema can have a table in it called schemaversion(version
text primary key, notes text); with an entry there something like
'1.0','initial schema'.

Each delta .sql file you create would then have an insert into the
schemaversion table with the version number it brings the schema up to
and a note of possibly the change ticket or bug number or even a brief
overview of the changes it implements.

That way you can have a production schema at some stable version, say
1.0.8, while your development schema can move ahead to 2.0.4.  then
you can simply apply the delta files to take you from 1.0.8 to 2.0.4
when you want to upgrade production.

Store each of these files in some directory in svn and you're done.

My point being that you need to drive the changes from the svn side,
not the database side.  I've seen no reliable way to do it otherwise,
but would love to be pleasantly surprised.

On Wed, 1 Aug 2007 11:46:11 -0500
"Scott Marlowe" <scott.marlowe@gmail.com> wrote:
> On 8/1/07, John Mitchell <mitchelljj98@gmail.com> wrote:
> > I am trying to store schema definitions in version-control which I can do by
> > saving the definition and then  importing  into svn, but I  would like  it
> > to be automatic , so that when an update occurs to a table or view within
> > postgres then that table or view is flagged within svn.  This would be
> > similar to what I currently do with source code that I have for a web app
> > within  eclipse.
>
> My point being that you need to drive the changes from the svn side,
> not the database side.  I've seen no reliable way to do it otherwise,
> but would love to be pleasantly surprised.

You are right.  It is always difficult to add structured control to
unstructured development methods.  The method that I suggested was the
best I could think of to handle a database that is changed ad hoc with
no design work beforehand.  If you work from the design side first you
can create schema documents that feed your database creation and use
svn to save those versions and document exactly why things changed.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Aug 1, 2007, at 1:17 PM, D'Arcy J.M. Cain wrote:

> On Wed, 1 Aug 2007 11:46:11 -0500
> "Scott Marlowe" <scott.marlowe@gmail.com> wrote:
>> On 8/1/07, John Mitchell <mitchelljj98@gmail.com> wrote:
>>> I am trying to store schema definitions in version-control which
>>> I can do by
>>> saving the definition and then  importing  into svn, but I  would
>>> like  it
>>> to be automatic , so that when an update occurs to a table or
>>> view within
>>> postgres then that table or view is flagged within svn.  This
>>> would be
>>> similar to what I currently do with source code that I have for a
>>> web app
>>> within  eclipse.
>>
>> My point being that you need to drive the changes from the svn side,
>> not the database side.  I've seen no reliable way to do it otherwise,
>> but would love to be pleasantly surprised.
>
> You are right.  It is always difficult to add structured control to
> unstructured development methods.  The method that I suggested was the
> best I could think of to handle a database that is changed ad hoc with
> no design work beforehand.  If you work from the design side first you
> can create schema documents that feed your database creation and use
> svn to save those versions and document exactly why things changed.

Another good idea is to include in these delta (or migration) scripts
the necessary sql to rollback the change.  Then it's not too hard to
write a tool that you can give db connection params and a version #
to sync to.

Erik Jones

Software Developer | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com