Model Inheritance: Mixin Use Cases
Joseph Kocherhans
(preferably simple code samples) Basically, are people wanting
multiple inheritace for models, or do you just want a mixin to provide
some additional methods? I'm reasearching model inheritance a bit
more, and realized that I have no idea what people are looking for
when they say "I want mixins". If you just want to update the wiki,
that's cool too.
http://code.djangoproject.com/wiki/ModelInheritance
Also, if you are *actually* working on model inheritance, or planning
to, please speak up. I don't know of anyone who's dedicating time to
it at this point.
Joseph
Andy Dustman
>
> Could anyone who want's mixins post some specific use cases
> (preferably simple code samples) Basically, are people wanting
> multiple inheritace for models, or do you just want a mixin to provide
> some additional methods? I'm reasearching model inheritance a bit
> more, and realized that I have no idea what people are looking for
> when they say "I want mixins".
Here's a use case for something that I'm actually working on: An
administrative tool for djbdns's tinydns. Record format details are
here:
http://cr.yp.to/djbdns/tinydns-data.html
General idea is to have one class/table for each record type. Note
that all the records have some common elements: domain, ttl, timestamp
(which I'm doing as starts and expires timestamps), and location.
Additionally I would add some per-record metadata: added and updated.
Also there would be some common methods.
At present (in magic-removal), If I make a BaseRecord type with all
the common attributes and then make other records subclass it (not
exactly what you are asking for with mixins), I can create new entries
fine, but I can't access them through the admin interface because it
tries to pull them out of the wrong table (the superclass table).
I also tried having the common elements as a mixin, but that didn't
work right either. (I may have to revisit this, though.)
I have some notes on the ModelInheritance page about possibly using
views to simplify reading, and while none of the databases I could
find could do a multi-table update through a view without writing
stored procecures and triggers, I realized that individually updating
the underlying tables is no worse than if you didn't use views. So
views seem to be a win for reading and neutral for writing.
--
The Pythonic Principle: Python works the way it does
because if it didn't, it wouldn't be Python.
Joseph Kocherhans
>
> At present (in magic-removal), If I make a BaseRecord type with all
> the common attributes and then make other records subclass it (not
> exactly what you are asking for with mixins), I can create new entries
> fine, but I can't access them through the admin interface because it
> tries to pull them out of the wrong table (the superclass table).
>
> I also tried having the common elements as a mixin, but that didn't
> work right either. (I may have to revisit this, though.)
Neither mixins nor subclassing really work at this point. At all. Some
of the plumbing has been done (adding fields of all the parents to a
subclass), but any type of select will not work. If it does, I'd have
to call it crazy coincidence.
> I have some notes on the ModelInheritance page about possibly using
> views to simplify reading, and while none of the databases I could
> find could do a multi-table update through a view without writing
> stored procecures and triggers, I realized that individually updating
> the underlying tables is no worse than if you didn't use views. So
> views seem to be a win for reading and neutral for writing.
I thought the same thing, but I was both pessimistic and lazy. I
didn't beleive that the 3 main players (postgres, mysql, sqlite) would
all let you update and insert on views, and I didn't reasearch it to
make sure :)
I'm not convinced that the wiki discusses the best method for Django.
Martin Fowler discusses 3 main inheritence patterns in PEA, and that
said, rails ActiveRecord, SQLObject, and SQLAlchemy all pick a
different one. (AFAICT anyhow, someone correct me if they know
differently. SQLAlchemy probably has the potential to do all 3, but
it's certainly not any kind of "out of the box" or documented type
thing.)
IMHO, supporting all 3 models is out of the question for Django. If
someone really needs an ORM that flexible, they shouldn't be using
Django's ORM. Each method has tradeoffs, so I'll try to summarize them
all in the next week or so.
Joseph
Andy Dustman
> > I have some notes on the ModelInheritance page about possibly using
> > views to simplify reading, and while none of the databases I could
> > find could do a multi-table update through a view without writing
> > stored procecures and triggers, I realized that individually updating
> > the underlying tables is no worse than if you didn't use views. So
> > views seem to be a win for reading and neutral for writing.
>
> I thought the same thing, but I was both pessimistic and lazy. I
> didn't beleive that the 3 main players (postgres, mysql, sqlite) would
> all let you update and insert on views, and I didn't reasearch it to
> make sure :)
I'm not sure if this was clear, but at least MySQL-5.0, MS-SQL, DB2,
and Oracle appear to allow you to update views that are based on
joins, provided you only update underlying one table at a time. To
update multiple tables, you need to use triggers (rules in the case of
PostgreSQL, and I'm not sure views are updatable in PostgreSQL at all
without writing a rule for each view) and stored procedures. However,
the alternatives are updating the underlying tables with individual
queries, or updating them using the view, but then you have to make
sure you aren't touching more than one table at a time. I.e. if your
class is spread across three tables, you'd have to make up to three
queries when making an update, depending on what attributes/columns
changed.
The simpler alternative is close to what it does now: A subclass gets
it's own tables, and inherits fields from the parent class. Right now
it inherits the fields, but it seems like it also inherits the table
name as well for select. And they don't inherit ManyToMany relations
yet, but should.