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
>
