As I further test the pythonic inheritance for models, I figure out
that some django model magic does not work. For example, instead of
"get_object_or_404" you should do:
try:
object = ObjectClass.objects.get(pk=1)
except:
raise Http404
On 17 Temmuz, 18:01, omat <[EMAIL PROTECTED]> wrote:
> Sorry for the terminological confusion. The "model" is the
> django.db.models.Model() class, the "manager" is the
> django.db.models.Manager() class.
>
> Yes Nis, the behaviors you listed are the most important ones. It
> would be nice to have Meta, Admin, etc. inherited as well but, it is
> not a priority. I think, with that requirements, pure pythonic class
> inheritance is just fine. It gives a single table for each model,
> which sounds quite natural.
>
> For the side effect, as Carl has pointed out, as long as you don't put
> "ortho" in the settings.INSTALLED_APPS, it is not recognized by
> syncdb.
>
> Yours,
> oMat
>
> On 17 Temmuz, 17:14, Carl Karsten <[EMAIL PROTECTED]> wrote:
>
> > Nis Jørgensen wrote:
> > > omat skrev:
> > >> Thanks for the pointer, Nis.
>
> > >> Model inheritance made my models so much DRYer that it will be hard to
> > >> give up, at least psychologically...
>
> > >> And, except for the managers, it worked just as I would expect, and
> > >> for the managers, it was easy to patch.
>
> > > Just to make sure I understand, your expected behavior is
> > > - Each model gets a db table which include fields from its ancestors
> > > - Managers and (other) methods are inherited as if they were defined on
> > > the subclass
> > > - There is no common interface for subclasses of a model class.
>
> > > Correct?
>
> > > I would perhaps call this "class templating" rather than "subclassing",
> > > but I can definitely see its usefulness.
>
> > I think the name problem stems from "model" not being well defined, or notr
> > properly used. Is the model the class, the persistence implemented in the
> > db,
> > the shape of the data...?
>
> > I agree that what is bing described here is very different than some of the
> > other discussions that use the same terms. which makes it very confusing.
> > (the
> > other discussions seem to focus around a separate table for each level of
> > subclass.)
>
> > I am currently trying out what is discussed in this thread, and figured out
> > the
> > same hack: db_table = 'message' - Some time this week I hope to have things
> > working well enough to post the whole app
> > inhttp://groups.google.com/group/django-hotclub
>
> > > Note that you get the probably undesired sideeffect of defining the
> > > Ortho class as a model - which may cause some confusion if people use
> > > syncdb and friends, and probably in other cases as well.
>
> > So far syncdb has not found my abstract class. I have it in a separate dir
> > not
> > referenced by INSTALLED_APPS. guessing that is the trick, but I am not 100%
> > sure how syncdb finds classes.
>
> > Carl K
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
