Bug in model inheritance?
This looks quite a bit like a bug, but we may be off the reservation in terms of how we're using the product. (Disclaimer: I'm relatively new to Django, and extremely new to the codebase that I ran into this on). We've got a form of schema-inheritance going on in this project in order to accomplish shared-id-space and the ability to relate models to one of a number of different types. The way that we've broken it out runs us into a strange inconsistency in Django that specifically affects our ability to serialize the objects. Here's a simplified version of what we're doing: class Entity(models.Model): entityType = models.CharField(editable=False,max_length=50) def __init__(self, *args, **kwargs): super(Entity, self).__init__(*args, **kwargs) self.entityType = self.__class__.__name__ def __unicode__(self): return 'Entity: %s %s' %(self.entityType, self.id) class BasePerson(Entity): entity = models.OneToOneField(Entity, parent_link=True) name = models.CharField(max_length=50) class Meta: abstract = True class Kid(BasePerson): school = models.CharField(max_length=50) class Adult(BasePerson): job = models.CharField(max_length=50) When I dump instances of these models out using the standard fixtures serialization, instances of Kid will serialize the 'entity' field, but instances of Adult won't. The reason is because Adult's entity field is marked primaryKey=True. Kid's is not. There appears to be a caching issue here, because if I swap the order that Kid and Adult are defined in.. the error reverses (now Kid's field will be marked pk). Is this a bug? If not, what's the reasoning behind this behavior? Is there a better pattern for accomplishing this kind of inheritance? Thanks in advance for your help. Phill -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Bug in model inheritance?
Alec, Thanks.. yeah, your fix forces the fields to pk=True, which doesn't redundantly serialize the field with it's custom name in my case. If for some reason you wanted to ensure that the field was serialized using it's custom field name though.. there doesn't appear to be a way to do that. I'm pretty convinced this is a bug. Phill On Sep 28, 11:12 am, Alec Shaner wrote: > As to whether it's a bug or not I have no idea, though it seems so. > > If you use: > > entity = models.OneToOneField(Entity, parent_link=True, primary_key=True) > > it will create the primary key in both Kid and Adult tables, which > sounds like what you want? > > > > On Tue, Sep 28, 2010 at 1:06 PM, phill wrote: > > This looks quite a bit like a bug, but we may be off the reservation > > in terms of how we're using the product. (Disclaimer: I'm relatively > > new to Django, and extremely new to the codebase that I ran into this > > on). > > > We've got a form of schema-inheritance going on in this project in > > order to accomplish shared-id-space and the ability to relate models > > to one of a number of different types. The way that we've broken it > > out runs us into a strange inconsistency in Django that specifically > > affects our ability to serialize the objects. Here's a simplified > > version of what we're doing: > > > class Entity(models.Model): > > entityType = models.CharField(editable=False,max_length=50) > > > def __init__(self, *args, **kwargs): > > super(Entity, self).__init__(*args, **kwargs) > > self.entityType = self.__class__.__name__ > > > def __unicode__(self): > > return 'Entity: %s %s' %(self.entityType, self.id) > > > class BasePerson(Entity): > > > entity = models.OneToOneField(Entity, parent_link=True) > > name = models.CharField(max_length=50) > > > class Meta: > > abstract = True > > > class Kid(BasePerson): > > school = models.CharField(max_length=50) > > > class Adult(BasePerson): > > job = models.CharField(max_length=50) > > > When I dump instances of these models out using the standard fixtures > > serialization, instances of Kid will serialize the 'entity' field, but > > instances of Adult won't. The reason is because Adult's entity field > > is marked primaryKey=True. Kid's is not. There appears to be a caching > > issue here, because if I swap the order that Kid and Adult are defined > > in.. the error reverses (now Kid's field will be marked pk). > > > Is this a bug? If not, what's the reasoning behind this behavior? Is > > there a better pattern for accomplishing this kind of inheritance? > > > Thanks in advance for your help. > > > Phill > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Inverting URL security diligence - suggestions?
I'm interested in inverting the diligence required to lock down URLs for my Django app. That is to say, today we put decorators that are some form of @login_required on view methods that require auth, and no decorators on views that are wide open. I'd like to invert that (or force decorators on both). I played around with things like having the decorators pin an attribute to the function and then use a bit of middleware to assert the attribute exists. It runs into issues though, when it comes to using third party views like auth_views, etc. In general, I'm worried it might be too fragile. I'm curious if anyone's familiar with a robust strategy for achieving this. Seemed like something that might be a common request for apps that do most of their work under auth. Thanks in advance, Phill -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/_Ilw1T03j7MJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
