Oh okay, apparently there is a ticket from 4 years ago http://code.djangoproject.com/ticket/4459
On Mar 30, 5:21 pm, George Karpenkov <true.chesh...@gmail.com> wrote: > If we'll look into core/management/commands/loaddata we'll see the > line > "obj.save(using=using)" which saves the data. > > *however* consider the case when application has some custom database- > altering logic in .save method. The common thing that comes to mind is > timestamp, or something similar. What would happen is that instead of > loading data the data from the fixture will be partly changed, which > is really not what you want. > > That's not the worst case though - I've just spent 40 minutes loading > the database from a fixture which contained data in django-tagging, > which inserts it's own "INSERT" SQL statements into save. So loaddata > was consistently crashing with "column blah is not unique" while the > data from the dump was perfectly fine. It made me quite sad. > > so coming to think of it i can't really think of a use case where > you'd want the custom logic in .save() to be executed. All the data is > already there, and we *know* that it is valid data - so what else we > might possibly want to do with it? (unless our application > communicates over network with different services and it uses .save() > to maintain integrity with them, but I haven't seen a single django > website like that) > So I think that some lower-level logic should be called instead. > > Any comments on why loaddata was implemented this way in the first > place? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
