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
