On Oct 20, 2011, at 4:03 AM, Alex K wrote:
>
> result2 = db.session.query(non_primary_mapper).from_statement('SELECT test.id
> AS test_id, test.user_id AS test_user_id, test.reply_id AS test_reply_id,
> test.text AS test_text FROM test LEFT OUTER JOIN "user" ON "user".id =
> test.user_id LIMIT 1 OFFSET 0').options(contains_eager(Test.user)).all()
There's absolutely no reason above you'd need to use a non primary mapper
there. The primary mapper for Test is already Test.__table__. When you use
from_statement(), the underlying table to which the class is mapped is entirely
disregarded - the columns in the string statement are assigned to the Test
object as well as the related User using a naming convention. You'd need to
add all the "user" columns you'd like to load to the columns clause of the
SELECT statement, using the convention <usertablename>_<columnname>. non
primary mappers can't be used to add new columns to a mapping or to change the
names of existing columns, so that isn't happening here either. The Test and
User classes once mapped to their primary tables get their attribute names
assigned and that's it.
non primary mappers are almost entirely useless these days except for this one
edge case involving relationship() to a non primary as the target, in order to
emit custom SQL from that relationship, which is not the case here since you're
writing the SQL by hand.
--
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.
