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.
