Setting Django 'unique' model field parame

Question

I have a 'project' Model and I've created 4 of them with the names 'Alan Parson's', 'Gutenberg', 'Gutenberg' and 'X.'

I just realized, I want the names to be unique, so I set unique = True on the project.name field

Now, I can't create another 'Gutenberg' or 'X' or whatever, but django has no issue with the fact that previous models have non-unique names.

How is django ensuring uniqueness of the new fields? Why doesn't it matter that old ones are non-unique, and -in general- is there anyway to tell which model field attributes (null, blank, unique...etc) are going to require a 'hard' change to the db schema and a migration?

---

looks like if I try and edit one of the existing projects with a non-unique name (from a model form), I get an error about how the name is non-unique, but I can access these models no problem and even add other objects to their many to many fields without a warning. This ties into my last question - seems like some of the parameters specified on the models dictate how their model forms work and not how they do. I think blank = true means model form fields can be empty, but null = true is 'stronger' in that it means it is ok if the actual field itself is data-less.

So, basically, is there any way to easily see which parameter changes necessitate a migration or 'hard' db change

Answer 1

The documentation for unique says:

This is enforced at the database level and by model validation.

The behavior you're describing sounds like you're getting the model validation part (e.g. what Django does when you try to add a new object using a ModelForm) but not the database constraint part; and that almost surely means that you didn't successfully create and run a migration after changing your model.

More broadly, you correctly note that some model field parameters affect Django's behavior and some affect the database. null creates a database constraint, whereas blank affects ModelForms. db_index affects the database, whereas default is always handled by Django. And unique affects both.

"So, basically, is there any way to easily see which parameter changes necessitate a migration or 'hard' db change?"

The easy way to see if a migration is necessary is to run makemigrations. If it creates a migration, then it was necessary, and you should run it. As the documentation says, though, that doesn't mean that your changes are touching the database:

Django will make migrations for any change to your models or fields - even options that don't affect the database - as the only way it can reconstruct a field correctly is to have all the changes in the history, and you might need those options in some data migrations later on.

For most purposes the distinction doesn't really matter; but if you care, the best ways to tell are by reading the documentation about the parameter and by looking at the generated migration to see what operations are being performed.