Code

Opened 4 years ago

Closed 2 years ago

#12610 closed New feature (duplicate)

Fixture loading is interfered by signal handlers

Reported by: jtiai Owned by: nobody
Component: Core (Management commands) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

If profiles are setup as documented using unique foreignkeyand post_save signal it's impossible to import both as a fixture since creating user data creates (empty) profile that conflicts with fixtures to be loaded.

Specially it's inconvenient in testing. There should be option to disable or run signals deferred while loading fixture data.

Attachments (0)

Change History (5)

comment:1 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

There is already a hook to check for this - data saved during a fixture load is loaded 'raw', and the 'raw' argument is passed to the pre/post save handlers. If you modify your pre/post save handlers to do nothing in the case of a raw save, you should be able to load fixtures without the problems you describe.

There might be an argument to be made that raw saves should disable signals completely - after all, the purpose of raw save is to prevent any clever 'on save' logic from being executed, and excluding signals from that process would make some sense. However, this could also be considered a backwards incompatibility. Marking DDN until we make that decision. Feel free to raise this on django-dev if you want to promote the idea.

comment:2 follow-up: Changed 4 years ago by thcourbon@…

I allow myself to bump this issue. I just came across this behavior. As far I'm concerned the current way to deal with fixture loading and signal handling by passing the 'raw' parameter is fine but it need documentation since their is nothing on that in http://docs.djangoproject.com/en/1.2/topics/signals/ or in http://docs.djangoproject.com/en/1.2/ref/django-admin/#loaddata-fixture-fixture.

If needed I would be pleased to contribute and write the required documentation in the right place.

comment:3 Changed 3 years ago by mattmcc

  • Severity set to Normal
  • Type set to New feature

comment:4 Changed 3 years ago by vanschelven

  • Easy pickings unset
  • UI/UX unset

This appears to be closely related to #8399

comment:5 in reply to: ↑ 2 Changed 2 years ago by aaugustin

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

Replying to thcourbon@…:

As far I'm concerned the current way to deal with fixture loading and signal handling by passing the 'raw' parameter is fine but it need documentation since their is nothing on that in http://docs.djangoproject.com/en/1.2/topics/signals/ or in http://docs.djangoproject.com/en/1.2/ref/django-admin/#loaddata-fixture-fixture.

The "raw" parameter was added in Django 1.3. That's why it isn't visible in the documentation for Django 1.2.

https://docs.djangoproject.com/en/dev/ref/signals/#django.db.models.signals.post_save

Russell provided a solution for this particular case, and #8399 tracks the more general question of disabling signals during fixtures loading.

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.