#22690 closed Bug (fixed)
'Proxy model contains model fields' error
| Reported by: | Craig de Stigter | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 1.7-beta-2 |
| Severity: | Release blocker | Keywords: | |
| Cc: | cmawebsite@… | Triage Stage: | Ready for checkin |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
My django-typed-models extension implements a type-field based model inheritance approach for django using proxy models.
It relies on having proxy models with their own fields, which has always worked with minimal hackery until recently.
Now on Django 1.7, we are getting this issue (ticket):
cdestigter@bob:~/c/tp$ ./manage.py syncdb
eh
Operations to perform:
Synchronize unmigrated apps: admin, contenttypes, auth, sessions
Apply all migrations: (none)
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
No migrations needed.
Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Users/cdestigter/checkout/django/django/core/management/__init__.py", line 427, in execute_from_command_line
utility.execute()
File "/Users/cdestigter/checkout/django/django/core/management/__init__.py", line 419, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/cdestigter/checkout/django/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/Users/cdestigter/checkout/django/django/core/management/base.py", line 337, in execute
output = self.handle(*args, **options)
File "/Users/cdestigter/checkout/django/django/core/management/base.py", line 532, in handle
return self.handle_noargs(**options)
File "/Users/cdestigter/checkout/django/django/core/management/commands/syncdb.py", line 24, in handle_noargs
call_command("migrate", **options)
File "/Users/cdestigter/checkout/django/django/core/management/__init__.py", line 167, in call_command
return klass.execute(*args, **defaults)
File "/Users/cdestigter/checkout/django/django/core/management/base.py", line 337, in execute
output = self.handle(*args, **options)
File "/Users/cdestigter/checkout/django/django/core/management/commands/migrate.py", line 141, in handle
changes = autodetector.changes(graph=executor.loader.graph)
File "/Users/cdestigter/checkout/django/django/db/migrations/autodetector.py", line 36, in changes
changes = self._detect_changes()
File "/Users/cdestigter/checkout/django/django/db/migrations/autodetector.py", line 54, in _detect_changes
new_apps = self.to_state.render()
File "/Users/cdestigter/checkout/django/django/db/migrations/state.py", line 64, in render
model.render(self.apps)
File "/Users/cdestigter/checkout/django/django/db/migrations/state.py", line 270, in render
body,
File "/Users/cdestigter/checkout/django/django/db/models/base.py", line 198, in __new__
raise FieldError("Proxy model '%s' contains model fields." % name)
django.core.exceptions.FieldError: Proxy model 'Hub' contains model fields.
This FieldError seems unnecessary and is not easily overridden without overriding the whole of ModelBase.__new__.
Can this FieldError please be removed (or extracted into a method that can be overridden, so I can remove this check for consenting subclasses)?
Otherwise I fear I may end up having to copy all 229 lines of ModelBase.__new__ into my code just to maintain this.
tested on latest 1.7.x.
Seems related: #22568
Marked as blocker cos it seems like a regression. Doesn't happen on 1.6.x or earlier
Change History (7)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Checks! Those look promising. Perhaps in Model._check_fields()?
That would work well for my app as I would only need to override that (much smaller) method to remove the check.
comment:3 by , 11 years ago
I've submitted a pull request for this: https://github.com/django/django/pull/2733
I ended up adding a new private method instead of putting it in Model._check_fields because it looks like 'field checks' are specific to a particular field, whereas this check is not so it seemed like it didn't belong there.
I'm not very familiar with checks but hopefully this can be quickly massaged into something adequate :)
comment:4 by , 11 years ago
| Triage Stage: | Unreviewed → Ready for checkin |
|---|
Looks good to me. This doesn't add any official support for proxy models with fields, but if users have existing code using proxy models with fields, then it will be possible to silence the error. Also, check instead of FieldError seems to be consistent with how other similar errors are handled.
comment:5 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:7 by , 11 years ago
| Cc: | added |
|---|
I also am using model fields on proxy models and I'll add overriding _check_model to my hacky code. (How else do you get virtual, non-database fields to show up both on the model _and_ in the admin?)
I'm not convinced this is something we want to support at all but I guess we could convert this to a check instead?