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

Sync some database tables, but not others ... WAS Re: How to modify ENUM datatypes?

From: "D(dot) Dante Lorenso" <dante(at)lorenso(dot)com>
To: Tino Wildenhain <tino(at)wildenhain(dot)de>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-general(at)postgresql(dot)org
Subject: Sync some database tables, but not others ... WAS Re: How to modify ENUM datatypes?
Date: 2008-04-25 17:10:47
Message-ID: 48121097.6040302@lorenso.com (view raw or flat)
Thread:
Lists: pgsql-general
Tino Wildenhain wrote:
> D. Dante Lorenso wrote:
>> Alvaro Herrera wrote:
>>> D. Dante Lorenso wrote:
>>>> Or, here's another way to look at it ... make it easier to modify 
>>>> ENUM  datatypes because we all know that you will eventually need 
>>>> that feature  whether you males, females, and unknowns think so or not.
>>> Agreed.  Let's keep in mind that the current ENUM implementation is
>>> completely new.
>>
>> Here's a use case that I doubt too many are aware of ... what's unique 
>> about ENUM is that the data for the ENUM becomes part of the schema of 
>> a database.
>>
>> This is actually something I like very much.  I have systems where the 
>> DEV and PROD databases are separate and must be synchronized when 
>> pushing out new features.  I currently use non-free tools to 
>> synchronize just the schemas for both databases.
>>
>> Often if a new row is added to a lookup table, that row doesn't make 
>> it to the QA or PROD databases because it's part of the data of a 
>> table and is not part of the schema.  For data (like ENUM data) that 
>> should be consistent across databases, it helps if it gets deployed 
>> with the schema so that lookups will succeed properly.
> 
> Well since its configuration and not payload its nothing wrong with just
> having the data in your repository as well and load it every time when
> you roll out a new release.

I have a convenient 3rd party tool that will "sync this database schema 
with that database schema".  I just run the tool, accept the discovered 
changes and voila, I've deployed the database changes to the next 
environment.

I haven't written any custom scripts to import content into specific 
tables.  As I see it, that would be a little complex also since you'd 
have to find the difference between dev and prod and only push the 
changes across (additions or deletes).  For potentially hundreds of 
small ENUM-like lookup tables, this seems quite tedious ... like the 
kind of thing a DB sync tool should handle for you ;-)

Perhaps there is a 3rd party tool that would not only sync the DB 
schema, but could add a list of tables which must also have their data 
synced?  Something that could remember that these 50 tables are 
"constant/deployable" and must be mirrored as-is to the other database 
while these other tables store environment-specific data and should not 
be synced.  Anyone know of such a tool?

-- Dante


> 
> Cheers
> Tino
> 


In response to

pgsql-general by date

Next:From: Rhys StewartDate: 2008-04-25 17:25:12
Subject: Re: query question really cant give a summary here so read the body ;-)
Previous:From: Colin WetherbeeDate: 2008-04-25 17:07:42
Subject: Re: query question really cant give a summary here so read the body ;-)

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