Errors for paths for Model relationships in other apps can be misleading / confusing

[andrei kulakov]

If a user is creating a relationship to a model in another app, it would be natural to use a path like: ForeignKey('app2.models.Model2'). This is consistent with e.g. urlconf where views are referenced like 'myapp.views.my_view', or generally django imports that use dots to separate elements of a full path.

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').

[andrei kulakov]

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.