Malcolm Tredinnick wrote:
> -----------------------
> 1. Abstract Base class
> -----------------------
> One use-case for subclassing is to use the base class as a place to
> store common fields and functionality. It is purely a "factor out the
> common stuff" holder and you don't ever intend to use the base class on
> its own. In the terminology of other languages (e.g. C++, Java), the
> base class it is an abstract class.
>
> At the database level, it makes sense to store the fields from the base
> class in the same table as the fields from the derived class. You will
> not be instantiating the base class (or querying it) on its own, so we
> can view the subclassed model as a flattened version of the parent +
> child. For example,
>
> class Thing(models.Model):
> name = models.CharField(...)
>
> class Animal(Thing):
> genus = models.CharField(...)
>
> class Toy(Thing):
> manufacturer = models.CharField(...)
In this case, they will simply be a list of fields with no
corresponding tables, managers, instances, data, .. etc. So they aren't
really models. Maybe we should consider them a different kind of
classes. Call them something like schema classes, or model templates.
This means that it will not be sufficient for their derivatives to
subclass them to become models, so they will be forced to use multiple
inheritance. Like this:
class Thing(models.Schema):
name = models.CharField(...)
class Animal(models.Model, Thing):
genus = models.CharField(...)
class Toy(models.Model, Thing):
manufacturer = models.CharField(...)
This alternative solution is clearer and better because:
1. It makes it clearer the fact that you cannot use Thing directly as a
model (because it is never thought of as a model anyway).
2. It makes the syntax for subclassing the abstract way and subclassing
the Pythonic way different in the definition of the derivative classes.
Two possible drawbacks:
1. It won't work if we need to inherit anything other than a commonly
used set of fields, but that should probably be the job of the Pythonic
inheritance.
2. I'm not sure weather multiple inheritance will be a feasible
solution in Python (because the code that is going to introspect the
Thing super class and add its fields to our class is model.Model, which
is one of the suer classes).
But I don't see this as a problem either, because we can always find an
alternative method of adding those fields to the model. We don't have
to use inheritance, because there is really no inheritance involved
here. We can simply declare the fact that we want to add a pre-defined
set of fields in the META section of the derivative class.
This would be the most extreme form of my reasoning:
fields_common_to_things = {name = models.CharField(...)}
class Animal(models.Model, Thing):
genus = models.CharField(...)
class META:
merge_fields = [fields_common_to_things]
class Toy(models.Model, Thing):
manufacturer = models.CharField(...)
class META:
merge_fields = [fields_common_to_things]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
