Thanks - I think I bumped into that yesterday and got distracted trying to setup a test on a win box (yay)
I was getting a 500, you too right? Carl K omat wrote: > 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 -~----------~----~----~----~------~----~------~--~---
