Code

Opened 6 years ago

Closed 6 years ago

#8118 closed (duplicate)

AlreadyRegistered exception is inaccurate on a second request with development server

Reported by: rokclimb15@… Owned by: nobody
Component: contrib.admin Version: master
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

In an admin module with multiple ModelAdmin classes defined, an inaccurate AlreadyRegistered will be raised on a second request if one of the models is registered twice.

To reproduce:
-Duplicate a call to admin.site.register in an admin module on a ModelAdmin class other than the first one (use the second class defined or any after that)
-Using the development server, try to load the site root (/)
-Note the accurate exception about the particular ModelAdmin class being registered twice
-Reload the page without restarting the development server
-Note the inaccurate exception about the first ModelAdmin in the module being registered twice, when in fact it is not

Attachments (0)

Change History (7)

comment:1 Changed 6 years ago by julien

  • Component changed from Uncategorized to Admin interface
  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to julien
  • Patch needs improvement unset
  • Status changed from new to assigned

This is strange indeed.

comment:2 Changed 6 years ago by julien

  • Owner changed from julien to nobody
  • Status changed from assigned to new
  • Summary changed from AlreadyRegistered is inaccurately raised on a second request to AlreadyRegistered exception is inaccurate on a second request with development server

Let's take this example:

class ProjectAdmin(admin.ModelAdmin):
    pass

class ParticipantAdmin(admin.ModelAdmin):
    pass

admin.site.register(Project, ProjectAdmin)
admin.site.register(Participant, ParticipantAdmin)

admin.site.register(Participant, ParticipantAdmin) # Register again

After a quick diagnosis, what I think is happening is:

  • First time: the validation does its job and raise the proper exception when the model is registered twice: "The model Participant is already registered".
  • Refresh (press F5): only the admin.py where the duplicated registration sits, is parsed. Yet, all the models are still registered in memory. Therefore, the exception is raised with the first model in the list: "The model Project is already registered".

I don't know if anything can be done about that. This is an issue that's related to the way the Development server works, and that doesn't appear to be critical.

comment:3 Changed 6 years ago by julien

Hmmm... after a second thought I'm not sure if it's an issue only with the development server. Because the exception is raised while admin.py is loaded, then it makes sense that only that module is reloaded again on a second request. Need to test that on an Apache server, for example, to figure that out.

comment:4 Changed 6 years ago by brosner

My guess on this problem is that Python re-imports urls.py again on the second request because the exception preventing it from making it to sys.modules. I would suspect this is a problem anywhere Python is. I just don't know how much can be done without changing the behavior of registration, which I disagree should happen. There may either be something I am missing however.

comment:5 Changed 6 years ago by brosner

Ignore my comment above. That was for another ticket. Why are we registering the same model twice? You shouldn't be doing that. Can you post some code to verify you are doing something wrong. It sounds like it.

comment:6 Changed 6 years ago by julien

Closing this one has dupe of #8245. I believe both tickets are different symptoms of the same problem, and #8245 has a patch that has the right approach.

comment:7 Changed 6 years ago by julien

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

Closing this one has dupe of #8245. I believe both tickets are different symptoms of the same problem, and #8245 has a patch that has the right approach.

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.