7

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?

TylerH
  • 20,799
  • 66
  • 75
  • 101
Joseph Turian
  • 15,430
  • 14
  • 47
  • 62

3 Answers3

10

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/

fredley
  • 32,953
  • 42
  • 145
  • 236
Emil Stenström
  • 13,329
  • 8
  • 53
  • 75
  • 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 – E.Serra Aug 03 '21 at 13:19
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.

Botond Béres
  • 16,057
  • 2
  • 37
  • 50
0

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.

Michael C. O'Connor
  • 9,742
  • 3
  • 37
  • 49
  • 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. – Joseph Turian Oct 24 '11 at 18:41
  • 1
    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. – Chris Pratt Oct 24 '11 at 19:06
  • @JosephTurian, since your fixtures are already written, I'm sure you can easily script something using the Django serialization libs (https://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. – Michael C. O'Connor Oct 25 '11 at 00:05
  • 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. – E.Serra Aug 03 '21 at 13:18
  • @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 – Michael C. O'Connor Aug 31 '21 at 15:02
  • 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. – E.Serra Oct 20 '21 at 13:05