Thanks Shawn That's helpful. I was actually looking at the manager documentation today thinking perhaps that was what I needed - but couldn't quite wrap my head around it. But knowing that it indeed is the way to go will no doubt provide the motivation I need.
(I have problems learning anything if I'm not sure it solves a problem I have). On Feb 20, 4:12 pm, Shawn Milochik <sh...@milochik.com> wrote: > Not only is it not a stupid question, but it's one of the best > possible types of questions. Any time someone comes in and makes it > obvious that they've thought about their problem and made an attempt > to solve it themselves, they get my respect. > > The easiest answer to your question is to make a custom manager (a > subclass of models.Manager) for your model. > > http://docs.djangoproject.com/en/1.2/topics/db/managers/ > > You can add your logic to an override of the get() of filter(), or add > an entirely new method, such as pending() or ready_to_send(). > > If your data grows to the point where this becomes unwieldy, you could > speed things up by using signals, so that instances of the model > represented by 'foo' in your example would update a field in your main > model when they are created, changed, or deleted. This would allow you > to use metadata in your main model instead of having to do the extra > joins on every database read. > > Shawn -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
