Question

I see that when you add a column and want to create a schemamigration, the field has to have either null=True or default=something.

What I don’t get is that many of the fields that I’ve written in my models initially (say, before initial schemamigration –init or from a converted_to_south app, I did both) were not run against this check, since I didn’t have the null/default error.

Is it normal?

Why is it so? And why is South checking this null/default thing anyway?

Answer 1

If you add a column to a table, which already has some rows populated, then either:

• the column is nullable, and the existing rows simply get a null value for the column
• the column is not nullable but has a default value, and the existing rows are updated to have that default value for the column

To produce a non-nullable column without a default, you need to add the column in multiple steps. Either:

• add the column as nullable, populate the defaults manually, and then mark the column as not-nullable
• add the column with a default value, and then remove the default value

These are effectively the same, they both will go through updating each row.

I don’t know South, but from what you’re describing, it is aiming to produce a single DDL statement to add the column, and doesn’t have the capability to add it in multiple steps like this. Maybe you can override that behaviour, or maybe you can use two migrations?

By contrast, when you are creating a table, there clearly is no existing data, so you can create non-nullable columns without defaults freely.