I’ve never once had to change a column definition. Sure in theory that option is available. Better option is to just add a new column with the correct definition then copy over existing data in the old column.

I don’t think that’s really a positive or negative.

And the point about migrations ideally being separate is really just your own opinion. I prefer having the database definition in the same source tree as the application, ideally just a .sql file in the project.

▲

stanac 7 hours ago | parent [-]

> Better option is to just add a new column with the correct definition

After that you won't be able to change column to NOT NULL. You would need migration to create new table with not null column, copy everything, drop old table and rename the new one.

Edit: unless the table is empty.

▲

yomismoaqui 6 hours ago | parent | next [-]

Wrong, you can change NOT NULL since 3.53:

https://sqlite.org/releaselog/3_53_3.html

	▲	stanac 6 hours ago \| parent [-]
		Released a month ago, thanks, didn't know.

▲

grebc 7 hours ago | parent | prev [-]

How do you migrate in place data that doesn’t convert between types while maintaining a strict condition like NOT NULL?

This is again a scenario I’ve never run into 20ish years of SQL.

▲

stanac 6 hours ago | parent [-]

You create a nullable column and then change it to not null. Which wasn't possible in SQLite until recently.

	▲	grebc 5 hours ago \| parent [-]
		I’m not sure what your original point is pointing out. Some data doesn’t convert is what I’m pointing out regardless of Postgres or SQLite.