model.save() not called when loading Django fixtures?

Question

I am overriding my Django model save() method, so I can do some extra sanity checking on the object. (Is save() the correct place to do this?)

It doesn't appear that my fixtures/initial_fixtures.yaml objects have their save() method called. How can I sanity-check my fixtures?

Perishing

Answer 1

As of Django 1.5, save() is NOT called:

When fixture files are processed, the data is saved to the database as is. Model defined save() methods are not called, and any pre_save or post_save signals will be called with raw=True since the instance only contains attributes that are local to the model.

https://docs.djangoproject.com/en/1.9/ref/django-admin/

Finis

this is the correct answer I agree, as for the correct place to check I would say the serializer????, but then I doubt that will be called through the fixtures – Misshapen

Answer 2

The .save() method is called during fixture loading as seen in https://code.djangoproject.com/browser/django/tags/releases/1.3.1/django/core/management/commands/loaddata.py?rev=17029#L174

If you use a different DJ version, you can check that but I'm quite sure it is called in older versions as well.

How are you checking if your objects have their save() method called?

And about doing this in .save(), if the sanity checks are non-trivial then I don't think it's a very good idea.

Saint

Answer 3

Your fixtures are assumed to be good data, not questionable input, so I'm not sure of a good case when you would need to be sanity checking them.

You can add data to your db through the admin or something within your app and then export that as a fixture, if you need to do some one-time initial validation.

Nimbus

If I am writing a lot of fixtures, it is possible there is a typo. Hence, I would like to use the models' sanity checks on the fixtures. I already have the fixtures written, so pushing them through the admin interface would be double work. – Perishing

You can't "sanity-check" your fixtures. That's the point. Fixtures are assumed to be clean. Michael is saying that it's better to create fixtures by using the admin to input the data in the first place, and then use dumpdata to get your fixtures. Otherwise, it's all on you to make sure the data is correct. – Quadrate

@JosephTurian, since your fixtures are already written, I'm sure you can easily script something using the Django serialization libs (docs.djangoproject.com/en/dev/topics/serialization) to read them in and save them normally (though it looks from another answer like the normal loaddata might already do something similar). Once you have done that once to ensure your data is clean, I'd export the known-good data as fresh fixtures just use the normal routine from there on out. – Epithelioma

how does this answer to wether the save method is callled or not?. My fixtures are perfect but for search purposes I process some fields and store them as a combination of other fields. fixtures loading like this crazy django way makes them null. – Misshapen

@E.Serra, The Django docs specify that .save() is not called when loading fixtures. If you want to use fixtures to store data but then do further processing during load, you'll need to use the serialization framework to manually load and save them, as I mentioned above – Epithelioma

Yes I understand that, it is just another django thing violating the least astonishment principle, I will definitely advocate for flask over django every day of the week. – Misshapen