Code

Opened 2 years ago

Closed 2 years ago

#17112 closed Bug (duplicate)

`ManyRelatedManager.add()` doesn't commit to database

Reported by: mrmachine Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Release blocker Keywords: add reverse m2m relation not committed
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Execute the following in order in two different interactive shells (two processes) to trigger the bug. The problem is that the call to .add() is not committed to the database until a second call to .create(). If the first process happens to be a management command (for example) and there are no subsequent database writes, the relations are never committed. You can also confirm this by inspecting the database after executing each command.

# shell 1
>>> from django.contrib.auth.models import *
>>> u = User.objects.create(username='test')
>>> u.groups.add(Group.objects.latest('pk'))
>>> User.objects.get(username='test').groups.all()
[<Group: motivate | members>]

# shell 2
>>> from django.contrib.auth.models import *
>>> User.objects.get(username='test').groups.all()
[]

# shell 1
>>> u2 = User.objects.create(username='test2')

# shell 2
>>> User.objects.get(username='test').groups.all()
[<Group: motivate | members>]

# sql command to check if group has been linked to user
select * from auth_user_groups where user_id = (select id from auth_user where username = 'test');

I've tested this against trunk, and it was confirmed by ptone who also confirmed that it is a regression from 1.3. I tested on PostgreSQL and SQLite.

I'm not sure how to create an automated test for this, because the problem only exhibits when reading from the database from a different process or transaction.

Attachments (0)

Change History (4)

comment:1 Changed 2 years ago by ptone

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

I can confirm that this works across processes in 1.3, but not in trunk

comment:2 Changed 2 years ago by julien

  • Severity changed from Normal to Release blocker

Marking as blocker since it's a regression.

comment:3 Changed 2 years ago by ptone

The changeset that introduces the problem is r16739 (git bef16bd6825d05fe48b0feb9b0e933686cc7099b)

comment:4 Changed 2 years ago by ramiro

  • Resolution set to duplicate
  • Status changed from new to closed

#16818 also reported this. I'm going to close this one as a duplicate adding as a comment there a copy of the note by mrmachine about why this isn't easily reproducible with our test suite (I wasn't able by simply adding a test case).

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.