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:
On the project that I work on, we have a default field similar to this:
When we run migrations on the project, we always get:
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:
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 fieldcDefault
field here (ie on column there iscNull
, there are also similar fields on other types), and I think it might be that in the case where there isNothing
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 defaultnull
value, in this case, we may not actually need to specifydefault=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