type-field model inheritance
Craig de Stigter
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']
Craig de Stigter
Stephen Burrows
retrieve various types of objects. There's an implementation of this:
https://github.com/bconstantin/django_polymorphic
Russell Keith-Magee
> I realise everyone's been busy with getting 1.3 ready, but doesn't anyone
> have thoughts on this? It's been two weeks ...
Hi Craig,
Thanks for the suggestion. As you've noted, we've been busy with the
1.3 release, which has been consuming a lot of the core team's time.
Sometimes posts fall between the cracks; your post is one such victim.
The other reason that you haven't got much traction is that this isn't
the first time your idea has been proposed. In fact, this suggestion
one of the design options on the table at the time that model
inheritance was originally proposed. It was rejected at the time on
the grounds that it was too much overhead to impose on a general
inheritance solution (i.e., DB columns aren't free, and many
applications of inheritance don't require the extra column). Search
django-dev for "CORBA narrow" for the full discussion and reasoning.
Since then, a couple of people have addressed this issue using mixins;
this enables you to get the subclassing+narrowing goodness by simply
annotating a class heirarchy. django_polymorphic (given in another
reply) is one such example; there are others.
Personally, I'd eventually like to see a contrib package that
contained extensions like this -- polymorphic models, tree
implementations and so on -- model extensions to represent common data
usage patterns. Ideally, this contrib app would be developed in the
same way that contrib.messages was handled -- a small team doing a
survey of the community to find all the model extensions like this
that exist (e.g., mptt, treebeard, polymorphic, and so on), and
pulling them together into a single project that covers all the use
cases spanned by each individual project. Then, once a single spanning
implementation exists (and is documented, tested, etc), it could be
proposed for inclusion in trunk.
Yours,
Russ Magee %-)
Craig de Stigter
Simon Meers
> Hi guys
>
> Thanks for pointing those out. I knew I couldn't have been the first to want
> this. I guess I just didn't know the right words to search for here.
> It looks like django_polymorphic does what I want. I'm not yet sure why it
> says it takes one query per type of model in a queryset. Unless it is
> talking about multi-table inheritance, in which each type would require a
> different join. But I'll look in more detail in the next few days and no
> doubt it will become clear.
+1 for better polymorphic support in Django core; it is a very common
problem which could do with an efficient and elegant solution.
Regarding efficiency, if you can keep track of your subclasses
effectively (potentially using a registry if not introspection), you
can use select_related to retrieve heterogeneous multi-table
inheritance models in a single query (see example in [1]). I haven't
looked deeply enough into django_polymorphic to see if it includes
such optimisations. I'm sure we could further tweak the internals to
make things more efficient and developer-friendly in this regard.
Cheers,
Simon
Carl Meyer
On Mar 4, 1:03 am, Craig de Stigter <craig...@gmail.com> wrote:
> It looks like django_polymorphic does what I want. I'm not yet sure why it
> says it takes one query per type of model in a queryset. Unless it is
> talking about multi-table inheritance, in which each type would require a
> different join. But I'll look in more detail in the next few days and no
> doubt it will become clear.
from abstract/proxy) supported by Django's ORM, I don't know what
other type of inheritance django_polymorphic would be referring to...
Carl
Carl Meyer
On Mar 4, 3:27 am, Simon Meers <drme...@gmail.com> wrote:
> +1 for better polymorphic support in Django core; it is a very common
> problem which could do with an efficient and elegant solution.
> Regarding efficiency, if you can keep track of your subclasses
> effectively (potentially using a registry if not introspection), you
> can use select_related to retrieve heterogeneous multi-table
> inheritance models in a single query (see example in [1]). I haven't
> looked deeply enough into django_polymorphic to see if it includes
> such optimisations. I'm sure we could further tweak the internals to
> make things more efficient and developer-friendly in this regard.
implements polymorphic queries in a single query via select_related.
[1] https://github.com/carljm/django-model-utils
Simon Meers
> FWIW, django-model-utils [1] includes an InheritanceManager that
> implements polymorphic queries in a single query via select_related.
Ah, there goes my theory that I thought of it first :) And of course
introspection of subclasses via the reverse OneToOne descriptors is
perfect.
Craig de Stigter
Since multi-table-inheritance is the only kind of inheritance (apart
from abstract/proxy) supported by Django's ORM, I don't know what
other type of inheritance django_polymorphic would be referring to...