-
-
Notifications
You must be signed in to change notification settings - Fork 301
Description
django-polymorphic 2.0.2, django 1.11.15
I came across an issue I wanted to make sure you're aware of -- I'm no longer using proxy models, so this is not affecting me currently.
Let's assume
class Parent(Model):
pass
Child(Parent):
pass
When using proxy models, the polymorphic ctype of a proxy of Child ended up making a new contenttype for ProxyChild in the django_contenttypes and pointing the Parent.polymorphic_ctype to it.
Now ... I was trying to generate these proxies dynamically, so that could be an issue, i.e.,
# From memory ... I think this is how I did it. Code is gone now.
def _proxy(cls):
class Meta:
proxy = True
p = type("%sProxy" % cls.__name__, cls, dict(Meta=Meta)
p.save = ... # I was overriding save on a bunch of these temporarily.
return p
ChildProxy = _proxy(Child)
I see here you seem to actually check ._meta for proxy, so perhaps this is just an issue with Meta not being properly created above.
....but this caused a secondary issue which took me a while to figure out. Since some ctype's were invalid, Child.objects.all() would return an empty queryset. Yet I could do Child.objects.get(id=xxx) for some objects. After wiping the db (it was dev instance), I later realized the root cause is possibly that Polymorphic is trying to (pre?)resolve all of the ctypes.
I'm wondering if this is the desired behavior -- I feel like polymorphic should instead either throw an exception when encountering bad ctypes, or it should ignore those instances. Instead it appeared to ignore even the proper ones.
I can put some effort into trying to reproduce this ... but would like the project's thoughts first. I think we can probably assume since I see proxy code in the code base that my dynamic proxy generation is the root issue. And we can ignore that ...
But do you know of any reasons why a couple of bad ctypes in Parent's table would make Child.objects.all() return nothing when there are some good entries still?