Thanks Michael, I was until now using a plain
row[u'layers_id_type'] found inspecting row.keys() with debugger (quick and ditry way, I know...) now I changed with your more orthodox row[mytable.c.id_type] (ahem...) I should not have to deal with subqueries so it can stay this way for the time being. I'm reading now for the first time in docs what's TypeDecorator for, and I understand (approximately, please allow me some time to dive into it) your suggestion. My doubt, at the moment is: using Type Decorator will I be able to keep using `mytable.c.id_type` as foreign key to types table (holding type name adn so on) or not? Probably reading docs better I'd get the answer by myself so don't mind... I'll post results if I reach some good point. Thanks again neurino On Fri, Jul 29, 2011 at 4:12 PM, Michael Bayer <mike...@zzzcomputing.com>wrote: > > On Jul 28, 2011, at 7:05 PM, neurino wrote: > > > I tried create_instance event and it fires, now having: > > > > def see_what_type(mapper, context, row, class_): > > if **is_air**: > > return Air() > > else: > > return EXT_CONTINUE > > > > def initialize_sql(engine): > > ... > > layer_mapper = mapper(Layer, layers) > > mapper(Air, inherits=layer_mapper) > > ... > > event.listen(Layer, 'create_instance', see_what_type, > > retval=True) > > > > and setting **is_air** as True I get Air instances querying for Layer > with filled attributes and relationships. > > > > I don't know about other caveats... > > > > Now I have to find a robust way to check id_type (one of `row` items) in > see_what_type. > > yeah thats one of the issues, those old extension interfaces were made > before we had the "aliased" row in place which happens with the more > elaborate subquery/join scenarios. > > For the simple case you'd run in the Column object into the row: > > row[mytable.c.type] > > if you start dealing with subqueries and such, might have to make it look > for a column that "proxies" the "type" column, which is entirely a > workaround for the bad interface: > > for key in row: > if key.shares_lineage(mytable.c.type): > value = row[key] > break > > but even that isn't going to work if you had two different Layer objects in > the same result row. > > Another workaround might be to establish the "type" of the "mytable.c.type" > column using a TypeDecorator - where process_result_value() performs the > rules you're looking for, returning "is_air" or not. Then you'd use > regular polymorphic_on. Maybe give that a try ? > > > -- > 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. > > -- 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.
