It sounds like you want to make polymorphic models - queries that
retrieve various types of objects. There's an implementation of this:
https://github.com/bconstantin/django_polymorphic
On Mar 2, 9:07 pm, Craig de Stigter <craig...@gmail.com> wrote:
> I realise everyone's been busy with getting 1.3 ready, but doesn't anyone
> have thoughts on this? It's been two weeks ...
>
> Thanks
> Craig
>
> On Thursday, February 17, 2011 11:08:57 PM UTC+13, Craig de Stigter wrote:
>
> > Hi folks
>
> > Ever since Django started supporting various types of model inheritance
> > I've wondered why it lacks the kind that I would find most useful: python
> > behaviour differentiated based on the value of a field.
>
> > I'll explain with an example. Here's what I'd like to do:
>
> > class Datasource(models.Model):
> > type = models.ModelTypeField()
> > uri = models.CharField(max_length=256)
>
> > # common behavior in the superclass
> > def __repr__(self):
> > return u'<%s: %s>' % (self.__class__.__name__, self.uri)
>
> > class HttpDatasource(Datasource):
> > # custom behaviour in the subclasses
> > def get_filename(self):
> > return self.uri.rsplit("/", 1)[-1]
>
> > class ZipfileDatasource(Datasource):
> > def get_filename(self):
> > files = zipfile.list(self.uri)
> > return files[0].rsplit('/', 1)[-1]
>
> > >>> zip = ZipfileDatasource.objects.create(uri="/path/to/foo.zip")
> > >>> uri = UriDatasource.objects.create(uri="http://example.com/foo.txt";)
>
> > >>> Datasource.objects.all()
> > [<ZipfileDatasource: /path/to/foo.zip>, <UriDatasource:
> >http://example.com/foo.txt>]
>
> > >>>ZipfileDatasource.objects.all()
> > [<ZipfileDatasource: /path/to/foo.zip>]
>
> > >>> Datasource.objects.all().values_list('type', flat=True)
> > [u'myapp.models.ZipfileDatasource', u'myapp.models.UriDatasource']
>
> > These are quite similar to proxy models, but vary in their queryset
> > behaviour - the generic Datasource queryset has mixed types and the concrete
> > querysets are always filtered by type.
>
> > This is far more useful than proxy models, since the concrete types of each
> > table are known. It's also better than making an abstract model and
> > subclassing it, because now all the objects are in the same table and you
> > can iterate over them all at once if you want. Adding more types is easy,
> > since there are no schema changes (with abstract models you'd have to add a
> > new table for each type).
>
> > It's possible that proxy models could be extended to do this without
> > breaking existing code. I'm not sure yet.
>
> > I'm thinking of diving into this. Does anyone have any suggestions? Or,
> > perhaps there's a reason why this hasn't been done previously that you more
> > experienced gurus could illuminate?
>
> > Thanks in advance
>
> > Craig de Stigter
> > Maintainer of django-mptt and full time dev at koordinates.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
