2011-02-27 29 views
8

Actualmente estoy trabajando en un archivo liquibase.xml para crear la tabla table_a. Uno de mis campos es <column name="state" type="ENUM('yes','no')"> Estoy usando postgresql como mi DBMS. ¿hay algo así como el tipo de datos enum? He leído en esto como http://wiki.postgresql.org/wiki/Enumtipo de datos enum para liquibase

que postgresql no tiene ese tipo de datos. La función CREATE TYPE se usa para crear este tipo de datos. Todavía no sé cómo hacerlo en liquibase sin embargo.

¿Alguna sugerencia?

Respuesta

14

Bueno, por supuesto, PostgreSQL tiene un tipo de enumeración (que está claramente documentado en el enlace que ha mostrado y el manual).

No creo Liquibase "nativa" es compatible con las enumeraciones para PostgreSQL, pero usted debería ser capaz de lograrlo con un SQL personalizada:

 
<changeSet id="1" author="Arthur"> 
    <sql>CREATE TYPE my_state AS ENUM ('yes','no')</sql> 
    <table name="foo"> 
    <column name="state" type="my_state"/> 
    </table> 
</changeSet> 

Para un simple sí/no la columna, que había hecho utilizar el tipo de boolean en lugar de una enumeración

+1

Esto parece sugerir lo contrario: https://gist.github.com/wilmoore/812253#file-modify-column-xml – 1in9ui5t

+0

También es una buena práctica proporcionar un comando de reversión al hacer sql personalizado en liquibase. http://www.liquibase.org/documentation/rollback.html – zudduz

1

una alternativa a la creación de un nuevo tipo sería un simple restricción CHECK en una columna de varchar(3):

<changeSet id="1" author="X"> 
    <table name="t"> 
     <column name="c" type="varchar(3)"/> 
    </table> 
    <sql>ALTER TABLE t ADD CONSTRAINT check_yes_no CHECK (c = 'yes' OR c = 'no')</sql> 
</changeSet> 

Eso podría jugar mejor con el lado del cliente, o no. Creo que boolean (como lo sugiere a_horse_with_no_name) sería una mejor opción para este caso específico: decir exactamente lo que quieres decir funciona mejor que las alternativas.

+0

Estoy de acuerdo: una restricción de verificación es probablemente incluso mejor que un ENUM –

+0

@a_horse_with_no_name: Pero un 'boolean' es probablemente mejor que el' CHECK' siempre que el cliente lado puede entender fácilmente un 'boolean' en la base de datos. Para el registro: me encantan las limitaciones de CHECK casi tanto como me encantan las FK; una base de datos altamente restringida es tu amigo. –

+0

No podría estar más de acuerdo;) –