@Mariusz
Thx for the update on the db support roadmap, helps alot to get things
into perspective.
@expression support
After a few more tests it turns out, that expression support prolly can
be saved exactly as it is by a combination of the current CASE chaining
with the VALUES table. At least sqlite and postgres support the
following format (mysql variants not tested yet):
UPDATE table SET f1 = CASE pk=1 THEN f2 ELSE foo.column2 END FROM
(VALUES (1, NULL), (2, 'Hello')) AS foo where table.pk = foo.column1;
This would be the result from something like
bulk_update([
Model(pk=1, f1=F('f2')),
Model(pk=..., f1=<literal value>),
...], ['f1'])
This again introduces the bad runtime of the CASE chains into the
statement, but only for objects using expression fields, so the user has
limited control over the runtime needs (dont use expressions if you want
very fast value pumping...)
Advantage of this - it should do exactly the same updates as the
bulk_update implementation (no weird ordering side effects), thus it
gets alot easier to prove, that the fast and fallback code path exhibit
the same update behavior.
Cheers,
jerch
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/754232be-68e1-1472-7371-2195688b32fa%40netzkolchose.de.
