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.
