Migration with is not idempotent when combining default=null and Maybe type

Abierto
  • ¿Algo no está bien?
#1,535 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
haskell, postgresql
Área
databases

Línea de trabajo

Comienza con la lógica de comparación de migraciones alrededor de Database/Persist/Postgresql.hs en la línea enlazada y después revisa la prueba de reproducción que falla en pull request 1534. Sigue cómo se representan los campos Maybe, el estado nullable y los valores predeterminados en newcols y en las columnas existentes. Se considera terminado cuando las migraciones repetidas ya no emiten ALTER TABLE ... SET DEFAULT null para este esquema y la prueba de regresión pasa.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

On the project that I work on, we have a default field similar to this:

SomeEntity
  name    Text Maybe    default=null

When we run migrations on the project, we always get:

ALTER TABLE "some_entity" ALTER COLUMN "name" SET DEFAULT null;

The column default gets set as 'nullable' in the database but every time we run migrations this ALTER TABLE is still output.

As with #1532 I looked at this by adding some logging here:

https://github.com/yesodweb/persistent/blob/a4b489032b9bb14a3637522aae89014b714494a4/persistent-postgresql/Database/Persist/Postgresql.hs#L1568

And looked in newcols and fst old' (the new columns vs existing columns), showing the field name and default value on the Column.

Here are the values that were logged out:

-- this is from `newcols`
(FieldNameDB {unFieldNameDB = "text_field"},Just "null")

-- this is from `fst old`
(FieldNameDB {unFieldNameDB = "text_field"},Nothing)

Different to 1532 where there is obviously a mis-match with the cases of the strings, I am less clear what is going on here. I am familiar enough with the types in persistent to know that the concept of nullable is also tracked beyond this field cDefault field here (ie on column there is cNull, there are also similar fields on other types), and I think it might be that in the case where there is Nothing for the default value the null has actually been converted into a flag to signal it being nullable somewhere else (while that hasn't happened on the parsed migration).

I'm not sure at all what the solution would be to this, but I'd be happy to also look to fix this too if I could get some steer in the right direction.

A key point to this issue is I think it is down to the fact that the field is already using Maybe in conjunction to a default null value, in this case, we may not actually need to specify default=null in our entity definitions, and that might be the solution here. But it may also be good for persistent to warn about this if you write this in your entity definitions.

I created a test to recreate this, there is an open PR with failing test here:

https://github.com/yesodweb/persistent/pull/1534

Lenguaje dominante
Haskell
Estrellas
486
Forks
307
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de yesodweb/persistent

Todos los issues de yesodweb/persistent

Issues similares

Más issues de Haskell

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.