On Sep 25, 2007, at 1:18 AM, [EMAIL PROTECTED] wrote:
> On Monday 24 September 2007 22:31:35 Michael Bayer wrote:
>> On Sep 24, 2007, at 12:13 PM, [EMAIL PROTECTED] wrote:
>>> it something to do with that expects thing...
>>> just do a x = str(b) before session.clear(), breaks it all.
>>
>> OK...that was just a *great* way to spend all day tracking that one
>> down. its fixed in 3515. I didn't bother to see why it doesn't
>> exist in 0.3, but its confusing that it doesn't, since the basic
>> mechanics of this one are present there as well, there must be some
>> subtlety which conceals it. I hope you can find more insanely
>> obscure bugs like this for me tomorrow !
>>
> now that u mentioned it... r3515 introduces something:
>
> File "/home/az/src/dbcook/sqlalchemy/orm/query.py", line 619, in
> __iter__
> return self._execute_and_instances(statement)
> File "/home/az/src/dbcook/sqlalchemy/orm/query.py", line 624, in
> _execute_and_instances
> return iter(self.instances(result))
> File "/home/az/src/dbcook/sqlalchemy/orm/query.py", line 680, in
> instances
> self.select_mapper._instance(context, row, result)
> File "/home/az/src/dbcook/sqlalchemy/orm/mapper.py", line 1360, in
> _instance
> discriminator = row[self.polymorphic_on]
> File "/home/az/src/dbcook/sqlalchemy/engine/base.py", line 1590, in
> __getitem__
> return self.__parent._get_col(self.__row, key)
> File "/home/az/src/dbcook/sqlalchemy/engine/base.py", line 1394, in
> _get_col
> rec = self._key_cache[key]
> File "/home/az/src/dbcook/sqlalchemy/util.py", line 72, in
> __missing__
> self[key] = val = self.creator(key)
> 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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
