Postgres: defaultValue not considered when changing from nullable to not-null.

[HarleySalas]

Link to reproduction

No response

Describe the Bug

In this instance,

I have a field named "maxLevel", which was not required and had no default value. I added a default value and switched it to required: true.

I received "Warnings detected during schema push", which was not expected, as I believe it should have used the defaultValue to fill the field, as it was empty. No big deal, I figured I'd just have to manually ensure that values were assigned before doing the schema push. I just thought it'd be annoying to have to do it in production with a large dataset.

I commented out the require part, then filled the data in manually, then uncommented and... "Warnings detected during schema push" again. I restarted the server. Couldn't seem to get rid of the warning. So, I pushed it. All documents were deleted, despite not violating the constraint.

To Reproduce

Create a Collection field without required: true.

add required: true and a defaultValue property.

Untested with other field types. Perhaps start with a number

Payload Version

2.0.15

Adapters and Plugins

@payloadcms/[email protected]

[jmikrut]

Hey @HarleySalas - thanks for the report. This makes sense to me. We have not implemented default values on the Postgres level, but probably could do so if the default value is statically defined rather than functionally defined.

Problem is that our default values can be defined with a function, and could leverage other data from the document in order to be defaulted. So our default values are in essence more powerful than typical Postgres default values.

So we could "patch" this, by setting default value accordingly if it is not set by a function, but this would be a new feature rather than an issue.

I too have run into the warning for setting existing fields to required though.

If you did manually go through and set default values for all rows in your table, and all of the rows in your table did indeed have values before you booted up Payload again, then this would be an issue for Drizzle rather than Payload because I would expect that Drizzle would see the change as being safe. I'm not sure how that works necessarily.

But I will convert this to a Discussion so we can at some point add a feature to "accept" statically defined default values on the database-level.

Thanks for the idea!

[r1tsuu]

Run into this too and i would say it's definitely not easy to change existing structure with required fields. And also it's easy to lose a data.
Can i make a PR with this? The only that i don't know yet is testing for this because existing tests are generic to database with local api, but here i probably would need to call the db directly

[DanRibbens]

Hi @r1tsuu,

A PR for this would be very appreciated!

You should be able to write the assertion for the test by accessing the drizzle table and expect the field to have a default value.

Based on the type, this should work:
expect(payload.db.tables[slug].columns[field].hasDefault).toStrictEqual(true)

I would also an assertion for another field that has a defaultValue function that should be false using the same expect() since we don't want the database to have a default if it is dynamic.