Fix creating models with multiple databases and with app label conflicts.

Review Request #10598 — Created June 18, 2019 and submitted

Information

Django Evolution
master

Reviewers

A few problems have been found when working with model creation.

When using multiple databases, we'd sometimes try to create models in
the database using the default database. This happened because we
weren't passing along the explicit database we're working with, which
is now a requirement for the function.

There was also an issue on Django 1.6 with working with models across
more than one app sharing the same legacy app label. When fetching
models for an app using Django's get_models(), it wouldn't actually
check that the models being returned are for the provided app, meaning
that we'd get the same models back more than once, hitting conflicts
when creating them. We now check this ourselves, making sure each
model's module resides somewhere within the app.

We also hit one other subtle issue where we were generating a list of
new models incorrectly. This was only used for the signals, but broke
some signal handlers out there. We now correctly turn this into a
flat list of new models.

Unit tests pass on Django 1.6 and 1.11.

Tested against Review Board, which had the app conflict issue.

Summary ID
Fix creating models with multiple databases and with app label conflicts.
A few problems have been found when working with model creation. When using multiple databases, we'd sometimes try to create models in the database using the default database. This happened because we weren't passing along the explicit database we're working with, which is now a requirement for the function. There was also an issue on Django 1.6 with working with models across more than one app sharing the same legacy app label. When fetching models for an app using Django's `get_models()`, it wouldn't actually check that the models being returned are for the provided app, meaning that we'd get the same models back more than once, hitting conflicts when creating them. We now check this ourselves, making sure each model's module resides somewhere within the app.
566f00f28bff252728e8196089a0c9d0a4f10c25
david
  1. Ship It!
  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to master (e1447bb)
Loading...