> > now that u mentioned it... r3515 introduces something:
> >
> > File "/home/az/src/dbcook/sqlalchemy/engine/base.py", line
> > 1304, in lookup_key
> > raise exceptions.NoSuchColumnError("Could not locate column
> > in row for column '%s'" % (str(key)))
> > NoSuchColumnError: "Could not locate column in row for
> > column 'pu_a.atype'"
> > ? failed A.query_SUB_instances: "Could not locate column in row
> > for column 'pu_a.atype'"
> >
> > pu_a is polymorphic union, and fails only if from_statement() is
> > involved.
>
> yeah thats exactly the "bug" that was "fixed". an Alias object
> now indicates to the ResultProxy to only match Column objects based
> on the exact labeled name of that column (which is normally
> tablename_columnname). maybe you can adjust your polymorphic_union
> and/or from_statement() to better match up. Theres possibly a way
> to make this work "both" ways (i.e. by only having eagerload
> aliases actually use this new flag, other kinds of aliases act the
> old way) but I want to see if you can work around it first.
well, i use this from_statement() for no better alternative to replace
the mapper's polymunion with another smaller one (subset of), without
making yet another secondary mapper.
So the smaller one was using same discriminator name of the big one.
now it's using themapper.polymorphic_on._label which seems to be what
u're looking for in the _exact_match case.
it does not work on 0.3. ah i can live with it, one more 'if _v03:..'
or i may turn this into another secondary mapper, maybe less trouble
(?)
anyway, all 10328 (joined) cases pass, have a nice day.
svilen
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
