Re: model managers of base classes
Are you working on a specific application that uses model inheritance, or testing the models I posted in the first message in this thread? Also, previously, you've mentioned something that you will post to another list. I didn't get that either. I was using the model api. The error is: Programming Error: relation "models_ortho" does not exist Naturally, if you access a view function that has this error via http, you will see Http500. Thanks, oMat On 17 Temmuz, 19:58, Carl Karsten <[EMAIL PROTECTED]> wrote: > 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 -~--~~~~--~~--~--~---
Re: model managers of base classes
My previous message did not appear for about an hour, so I am re- posting... 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 -~--~~~~--~~--~--~---
Re: model managers of base classes
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 -~--~~~~--~~--~--~---
Re: model managers of base classes
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 -~--~~~~--~~--~--~---
Re: model managers of base classes
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 -~--~~~~--~~--~--~---
Re: model managers of base classes
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 in http://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 -~--~~~~--~~--~--~---
Re: model managers of base classes
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. 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. Yours Nis Jorgensen --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: model managers of base classes
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.
Maybe I should further test them, or just give up until Django 1.0,
which, according to the discussions in the developers' list, will
probably have model inheritance implemented.
On 17 Temmuz, 14:32, Nis Jørgensen <[EMAIL PROTECTED]> wrote:
> omat skrev:
>
> > Hi all,
>
> > I have a base class common for all my orthogonal models, that is,
> > models that hold content for other models, such as tags. This base
> > class also has a manager. Here are the classes:
>
> > class OrthoManager(models.Manager):
> > def get_for_object(self, object):
> > ctype = ContentType.objects.get_for_model(object)
> > return self.filter(content_type__pk=ctype.id,
> >object_id=object.id)
>
> > def get_for_model(self, model):
> > ctype = ContentType.objects.get_for_model(model)
> > return self.filter(content_type__pk=ctype.id)
>
> > class Ortho(models.Model):
> > content_type = models.ForeignKey(ContentType,
> > editable=False,
> > blank=True,
> > null=True)
> > object_id = models.PositiveIntegerField(blank=True,
> > editable=False,
> > null=True)
> > object = generic.GenericForeignKey('content_type', 'object_id')
>
> > objects = OrthoManager()
>
> > When I define my orthogonal model like that:
>
> > class Tag(Ortho):
> > tag = models.CharField(maxlength=50)
>
> > and try to access its manager, I get a:
>
> > Programming Error: relation "models_ortho" does not exist
>
> > i.e. it looks for the "models_ortho" table.
>
> > If I add:
>
> > objects = OrthoManager()
>
> > to the Tag model class (the inherited class), it works fine.
>
> > It seems that I cannot inherit the manager of the base class. Is this
> > by design? Or am I doing something wrong?
>
> This is by "current" design - subclassing of models is not supposed to
> work yet. Here is a writeup of how it will likely work:
>
> http://code.djangoproject.com/wiki/ModelInheritance
>
> Since this is currently not supposed to work, I would think behavior is
> undefined. Thus i would suggest that you do not subclass models, even if
> you can get it to work.
>
> Nis Jørgensen
> (Eagerly awaiting model inheritance as well)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: model managers of base classes
omat skrev:
> Hi all,
>
> I have a base class common for all my orthogonal models, that is,
> models that hold content for other models, such as tags. This base
> class also has a manager. Here are the classes:
>
>
> class OrthoManager(models.Manager):
> def get_for_object(self, object):
> ctype = ContentType.objects.get_for_model(object)
> return self.filter(content_type__pk=ctype.id,
>object_id=object.id)
>
> def get_for_model(self, model):
> ctype = ContentType.objects.get_for_model(model)
> return self.filter(content_type__pk=ctype.id)
>
>
> class Ortho(models.Model):
> content_type = models.ForeignKey(ContentType,
> editable=False,
> blank=True,
> null=True)
> object_id = models.PositiveIntegerField(blank=True,
> editable=False,
> null=True)
> object = generic.GenericForeignKey('content_type', 'object_id')
>
> objects = OrthoManager()
>
>
> When I define my orthogonal model like that:
>
> class Tag(Ortho):
> tag = models.CharField(maxlength=50)
>
> and try to access its manager, I get a:
>
> Programming Error: relation "models_ortho" does not exist
>
> i.e. it looks for the "models_ortho" table.
>
> If I add:
>
> objects = OrthoManager()
>
> to the Tag model class (the inherited class), it works fine.
>
> It seems that I cannot inherit the manager of the base class. Is this
> by design? Or am I doing something wrong?
>
This is by "current" design - subclassing of models is not supposed to
work yet. Here is a writeup of how it will likely work:
http://code.djangoproject.com/wiki/ModelInheritance
Since this is currently not supposed to work, I would think behavior is
undefined. Thus i would suggest that you do not subclass models, even if
you can get it to work.
Nis Jørgensen
(Eagerly awaiting model inheritance as well)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
model managers of base classes
Hi all,
I have a base class common for all my orthogonal models, that is,
models that hold content for other models, such as tags. This base
class also has a manager. Here are the classes:
class OrthoManager(models.Manager):
def get_for_object(self, object):
ctype = ContentType.objects.get_for_model(object)
return self.filter(content_type__pk=ctype.id,
object_id=object.id)
def get_for_model(self, model):
ctype = ContentType.objects.get_for_model(model)
return self.filter(content_type__pk=ctype.id)
class Ortho(models.Model):
content_type = models.ForeignKey(ContentType,
editable=False,
blank=True,
null=True)
object_id = models.PositiveIntegerField(blank=True,
editable=False,
null=True)
object = generic.GenericForeignKey('content_type', 'object_id')
objects = OrthoManager()
When I define my orthogonal model like that:
class Tag(Ortho):
tag = models.CharField(maxlength=50)
and try to access its manager, I get a:
Programming Error: relation "models_ortho" does not exist
i.e. it looks for the "models_ortho" table.
If I add:
objects = OrthoManager()
to the Tag model class (the inherited class), it works fine.
It seems that I cannot inherit the manager of the base class. Is this
by design? Or am I doing something wrong?
Thanks,
oMat
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
