Model.save() incompatibilities

111 views
Skip to first unread message

Anssi Kääriäinen

unread,
Aug 28, 2013, 4:23:16 AM8/28/13
to django-d...@googlegroups.com
I just created a new ticket (https://code.djangoproject.com/ticket/20988), and marked it as release blocker for 1.6.

The summary of the issue is that there are some cases where the new save() algorithm will not save existing objects (for details about the algorithm, see #20988). This happens when an UPDATE of an existing row returns zero matched rows. At least PostgreSQL ON UPDATE triggers returning NULL can cause this condition. If an user is hit by this issue, then currently the options are to remove the trigger, or to use raw SQL for update of existing objects. There might be 3rd party backends or other conditions where the only option is raw SQL.

It would be nice to have better alternatives than raw SQL. Some options:
  - Change back to old algorithm.
  - Change the Model._do_update() to include forced_update flag. If this is done, it will be possible to override to _do_update() to use the old style algorithm. Unfortunately _do_update() is private API, but using that is likely better for most users than raw SQL.
  - Add a select_on_save flag now, that is before release. The flag effectively forces use of the old algorithm. The implementation is straightforward, see https://github.com/akaariai/django/commit/1ca398b0352b11868ec236f92cf17b6ce82ff88c. Docs missing, but otherwise ready.
  - Wait and see. If there are enough complaints, add select_on_save or some other workaround later on (that is, mid 1.6, or in 1.7).

In addition, better release notes about this issue are needed.

I think reverting to the old algorithm isn't a good option. The new algorithm will save one query in most cases. I will do the _do_update() signature change now, it is good for those who want to use that particular private API in any case.

The real question is should something be done about select_on_save flag now?

 - Anssi

Marc Tamlyn

unread,
Aug 28, 2013, 4:44:41 AM8/28/13
to django-d...@googlegroups.com
I think we should implement `select_on_save`. It gives the easiest way for someone to revert the feature if they need to. I know we're adding another Meta flag, but I'm not that concerned about that.


--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Anssi Kääriäinen

unread,
Aug 28, 2013, 5:04:40 AM8/28/13
to django-d...@googlegroups.com, Marc Tamlyn
I'll try to write a ready-for-checking patch ASAP. It is easier to discuss about concrete and full patch.

 - Anssi

Anssi Kääriäinen

unread,
Aug 28, 2013, 6:27:50 AM8/28/13
to django-d...@googlegroups.com, Marc Tamlyn
On Wednesday, August 28, 2013 12:04:40 PM UTC+3, Anssi Kääriäinen wrote:
I'll try to write a ready-for-checking patch ASAP. It is easier to discuss about concrete and full patch.
 - Anssi

Not quite ready yet, but patches for 1.6.x and master can be found from:
    1.6: https://github.com/django/django/pull/1522
    master: https://github.com/django/django/pull/1523

Proofread of docs needed. Reviews in general are very much welcome.

The select_on_save flag is a new feature (although a minor one). Any objections of adding it at this stage to 1.6?

 - Anssi
Reply all
Reply to author
Forward
0 new messages