Thanks a lot! The solution is so simple that I feel a little
embarassed...
On 16 Okt., 18:15, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Oct 16, 2007, at 10:45 AM, klaus wrote:
>
>
>
> > The only thing that I could find out about the reason is that in
> > engine/base.py (1290)
> > context.column_labels
> > contains the wrong entries. It should contain something like
> > {..., '<table>_<column>': '<table>_<column>', ...}.
> > In the case above, however, it contains
> > {..., '<table>_<column>': '<column>', '<column>': '<column>', ...}.
> > (That is, it contains two items for each column, but the values are
> > '<column>' instead of '<table>_<column>'.)
>
> > After that, I got lost. These values are generated by the postgres
> > driver. But I could not find where it takes its input from the Alias
> > object to generate something different than for the Table object.
>
> that is exactly correct, and was one of two issues present in 0.4.
> both issues, one of which occurs in 0.3 and 0.4 and the other just in
> 0.4 (though its hiding in 0.3 to some degree as well) originate from
> two distinct name confusions that arise because you're using the name
> of the table as the name of the alias. If you name the alias
> something other than "test" then all issues go away.
>
> so one issue was a hardcoded notion of bind parameter names used in
> the ORM by query.get(), which also is used for a many-to-one lazyload
> - it used the "label" of the column which in this case is "test_id",
> and conflicted with the existing "test_id" name (the compiler would
> rename the param as "test_id_1" but the Query object wasn't tracking
> that). So 0.3 now generates a "random" name whereas 0.4 uses
> anonymous bind parameters now (which are like "random" bind param
> names except they are compile-time generated in a deterministic
> fashion).
>
> second issue is that the column_labels dictionary was being populated
> with column labels from all selects embedded in the statement, not
> just the top level one, so again the "test_id" column at the top
> level conflicted with the embedded "id" column. since compilation
> maintains a stack of select objects, the fix is easy as it means we
> only operate when the stack is only one select object deep (i.e. its
> the outermost select).
>
> 0.3 rev 3624 and 0.4 rev 3625
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
