The error you would get looks like this:
app2.M1.f3: (fields.E300) Field defines a relation with model
'app3.models.M1', which is either not installed, or is abstract.
It might seem like it's not a big deal -- user just has to look at the
docs or google for the error.
However, in some cases it may lead to some loss of time, for example I had
circular foreign key dependencies between models for testing and thought
the error is due to circular references. More generally, django errors can
result from seemingly unrelated causes so if a user starts with a firm
assumption that a full path needs to be given, the error might lead them
to look for all kinds of workarounds to try before coming back to the path
format.
It would be easy for django to check the path and, if there are more than
one dot in path, and specifically if '.models.' is included in path, a
hint should be shown along with the error:
> NOTE: path should be of the form 'myapp.MyModel' and should NOT include
the name of module containing models (which is usually 'models').
--
Ticket URL: <https://code.djangoproject.com/ticket/24547>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* component: Migrations => Database layer (models, ORM)
* needs_tests: => 0
* easy: 1 => 0
* needs_docs: => 0
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/24547#comment:1>
* owner: nobody => akulakov
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/24547#comment:2>
Comment (by akulakov):
I no longer get the error in description, instead I get this traceback:
{{{
File "/Users/akulakov/projects/testproj/app1/models.py", line 4, in
<module>
class M1(models.Model):
File "/Users/akulakov/projects/django/django/db/models/base.py", line
158, in __new__
new_class.add_to_class(obj_name, obj)
File "/Users/akulakov/projects/django/django/db/models/base.py", line
294, in add_to_class
value.contribute_to_class(cls, name)
File
"/Users/akulakov/projects/django/django/db/models/fields/related.py", line
1819, in contribute_to_class
super(ForeignObject, self).contribute_to_class(cls, name,
virtual_only=virtual_only)
File
"/Users/akulakov/projects/django/django/db/models/fields/related.py", line
299, in contribute_to_class
lazy_related_operation(resolve_related_class, cls,
self.remote_field.model, field=self)
File
"/Users/akulakov/projects/django/django/db/models/fields/related.py", line
80, in lazy_related_operation
return apps.lazy_model_operation(partial(function, **kwargs),
*model_keys)
File
"/Users/akulakov/projects/django/django/db/models/fields/related.py", line
78, in <genexpr>
model_keys = (make_model_tuple(m) for m in models)
File "/Users/akulakov/projects/django/django/db/models/utils.py", line
13, in make_model_tuple
app_label, model_name = model.split(".")
ValueError: too many values to unpack (expected 2)
}}}
So it looks like this was changed and the original error can no longer be
triggered?
Unless there's some circumstances that can trigger the original error (I
couldn't find any -- tried both creating initial migration, creating a new
table, adding to existing table), this ticket should be closed.
--
Ticket URL: <https://code.djangoproject.com/ticket/24547#comment:3>
* status: assigned => closed
* resolution: => worksforme
--
Ticket URL: <https://code.djangoproject.com/ticket/24547#comment:4>