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

Re: Schema version control

From: Royce Ausburn <royce(dot)ml(at)inomial(dot)com>
To: Andy Colson <andy(at)squeakycode(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Schema version control
Date: 2011-02-11 03:08:25
Message-ID: C6E40F39-2656-4186-8F69-02E5E57623A7@inomial.com (view raw or flat)
Thread:
Lists: pgsql-general
> 
> So, 10.0 at 10057.
> 11.0 at 11023.
> 
> then 10.1 needs some fixes so db is bumped to 10058.
> 
> Then, later, you can upgrade 10057 to 11023, but you cant get 10058 to 11023.
> 
> Humm... maybe you need smarter upgrade scripts?  Would having logic in the script help?  Something like:
> 
> if not fieldExists('xyz) then alter table ...  add xyz ...
> 
> 
> 
> Or, maybe your schema numbering system is to broad?  Maybe each table could have a version number?
> 
> 
> Or some kinda flags like:
> create table dbver(key text);
> 
> then an update would be named: "add xyz to bob".
> 
> then the update code:
> 
> q = select key from dbver where key = 'add xyz to bob';
> if q.eof then
> 	alter table bob add xyz
> 


This is effectively the approach we've been working with so far, but it isn't great.  The issue is that you need to be really aware of what changes might or might not have been in the previous databases... This can be hard.

There's also the problem of updating data, etc.



In response to

pgsql-general by date

Next:From: Royce AusburnDate: 2011-02-11 03:09:44
Subject: Re: Schema version control
Previous:From: Royce AusburnDate: 2011-02-11 03:06:17
Subject: Re: Schema version control

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