On Tuesday 29 March 2016 13:19:01 Anssi Kääriäinen wrote:
>
> Personally I think we should just rename the method to fast_create()
> and allow it to fall back to single row at time behavior. This way you
> could safely call it for any objects on any database and know the
> results will be OK. I don't see much point in throwing errors when
> batch insert isn't possible. If batch insert isn't possible, the user
> needs to insert the values one row at a time in any case.
>
I beg to differ. fast_create() as you described will be suitable for some
users, but if creating 2000 records is going to require 2000 database
roundtrips, I'd appreciate a way to be told about it already when I'm testing
with 2. I could have other options to create the records (perhaps not using
the ORM at all), or I could decide early that the backend is unsuitable for my
needs.
For some optimizations, it is OK to just drop them if you can't do them. But
with bulk_create we could be talking about differences of orders of magnitude.
It seems to me that with that premise, the decision that it's ok to drop the
optimization should be explicit, and not Django's default.
My 2 cents,
Shai.
