Re:Django 1.4 final released
by ubernostrum on Friday March 23, 2012 @02:37PM
(#3746507)
This is the correct behavior, really. Bulk insert is not for cases where you have complex per-record validation or processing logic that also needs to be run in the application layer. It's for "I have all this data ready to go, now just shove it in there as efficiently as possible". If you need to have validation and additional per-record processing, signals, etc., insert the objects through the ORM normally. Yes, it'll be slower, but that's the price you pay for doing per-record processing.
Re:Django 1.4 final released
by notyourwork on Saturday March 24, 2012 @11:18AM
(#3749556)
To add to this, you could write your own validation method for a model and have your model's save method call this.
When processing bulk data sets you can iterate over calling your own validation then perform bulk insert knowing its validating. And your save will still validate as before.
Bulk updating already exists.
https://docs.djangoproject.com/en/dev/topics/db/queries/#upd...
Re:Django 1.4 final released
by joelhaasnoot on Friday March 23, 2012 @06:14PM
(#3747624)
And bulk updating also doesn't run any signals or the save method...
I don't like this because a lot of us put validation logic in Model#save and use the signals to trigger the search indexer, and so forth. This behavior is definitely going to catch some people off guard and it's bound to lead to serious bugs.
I understand why they don't call Model#save for every object, but I think they should have introduced something like Model#validate which is called before every save (including the new bulk inserts) so you still get a place to put custom validation logic that you know will get called the moment something is placed in the database. So now inserts are faster but at the expense of correctness. I'm not convinced that's a good trade off.
Oh, and for some reason bulk updates are completely missing, even though it seems natural to add bulk_insert and bulk_update at the same time.