Hi Melvyn,
2012/7/9 Melvyn Sopacua <m.r.sopa...@gmail.com>:
> On 9-7-2012 10:30, Daniel Walz wrote:
>
>> Ok, I did some tests today and read in the django sources.
>> It seems to me, that an abstract model class has no Manager attached,
>> at least not by default.
>
> Because an abstract model has no data. It is a collection of attribute
> definitions.
...but that's only the view from the data. But the data layer should
not influence the behaviour of the objects in my point of view. I
agree that this might be a matter of personal favor.
>
>> I see that, because my
>> AbstractFruits.objects.all() says "AttributeError: type object
>> 'AbstractFruits' has no attribute 'objects'", and as I understand
>> objects is the Manager() class.
>>
>> So it should be technically possible to implement a manager class for
>> abstract models which does a join of all subclasses... maybe somebody
>> takes the challange ;-)
>
> Not sure this is generally desired behavior. It is simple to implement this:
>
> class AbstractFruit(models.Model) :
> name = models.CharField(max_length=64)
> # more attributes
> class Meta :
> abstract=True
>
> class BaseFruit(AbstractFruit) :
> class Meta :
> ordering=['-name']
>
> class Apple(BaseFruit) :
> pass
>
> However, this introduces a MTI.
I'm sorry, I'm lost. can you explain me what is the benefit of the
intermediate class?
>
> An entirely different approach:
>
> class FruitType(models.Model) :
> name = models.CharField(max_length=32)
>
> class AppleManager(models.Manager) :
> def get_query_set(self) :
> apple = FruitType.objects.get(name='apple')
> return super(AppleManager, self).get_query_set().filter(
> type=apple))
>
> class Fruit(models.Model) :
> name = models.CharField(max_length=128)
> type = models.ForeignKey(FruitType)
> objects = models.Manager()
> apples = AppleManager()
That's a nice idea, but in that special case I think it's too much
overhead. But thanks anyway.
> On 7-7-2012 17:00, Daniel Walz wrote:
>
>> ...but using the django abstraction, what would happen, if I implement
>> this as MTI?
>> Say I implement the functions:
>> def Fruit.rott(): pass
>
> Abstract methods in python:
> def Fruit.rott(): raise NotImplementedError('This fruit cannot rot!')
>
> If you use a pass here, you won't notice subclasses not implementing the
> method, which can be what you want in the case of PlasticFruit, but in
> most cases you want to detect it.
That's nice, thanks I'm sure I'll use that on several places...
Best regards
Daniel
--
Daniel Walz - mcj...@gmail.com
Bremen, Germany
--
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.
