On Jul 15, 2012, at 10:03 AM, Karol Kuczmarski wrote:

> 
> Right, but as I've said before, it still has to be done on per-subclass 
> basis. I'm not sure how typical my use case,
> but it seems fairly reasonable that most of the time, the `type` attribute 
> would simply refer to polymorphic_identity
> directly:
> 
>     @property
>     def type(self):
>         return self.__class__.__mapper_args__['polymorphic_identity']
> 
> Ideally, one would expect some capability that allows to create "default 
> attribute implementation" that can be inherited in subclasses
> when it doesn't have appropriate column (in the mapped table) that could be 
> mapped into the attribute. I don't know how desirable
> such a feature would be, though, because cases when one declarative class 
> inherits from other and BOTH have a table mapped
> to them seem to be uncommon. Maybe even the (Abstract)ConcreteBase 
> hierarchies are the only practical application?...
> 
> In any case, thanks again for quick and insightful response. At least now I 
> know what's the state of this "feature" :)

I'd be uncomfortable just going forward with new behavior for the "type" 
attribute here and no others.  What if the the concrete base is non abstract, 
and has a whole host of other columns on it not present on other tables ?   
What about the case of more than one level of inheritance (there's always a 
tiny group of people who insist on making things that complex, so we have to 
oblige...)?  There should probably be a path that is generic.   

The solution to every class having a "type" attribute here can be done without 
repetition.   At the moment you'd need to name it something slightly different, 
like "type_", as the name "type" is hardcoded into the AbstractConcreteBase 
right now, but assuming that were configurable and the names could work out, 
you only need say:

class MyBase(AbstractConcreteBase):
    @property
    def type_(self):
       return self.__mapper__.polymorphic_identity


-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to