it would be a big favor if you could create a little standalone
program illustrating the various cases for me.
On Sep 27, 2006, at 11:24 AM, Dennis Muhlestein wrote:
>> you can now use the from_obj keyword parameter to Query.select(), and
>> it wont step on the tables you put in there:
>>
>> r = query.select(mytable.c.id==10, from_obj=[mytable.join
>> (myothertable)])
>>
>> you can put whatever x.join(y).outerjoin(z) type of thing into the
>> from_obj list. if the main mapped table is in there, then it will
>> use that as the only instance of that table in the FROM clause.
>>
>
> Thanks for the hard work. If I use the select syntax above, it works
> for the simple case. The correct query is generated.
>
> Here is a case that breaks though:
>
> Table A has two relations to other tables. Lets say I need to use
> the above syntax for one of the relations for the query to return the
> correct results, but the 2nd relation I just want to eagerload.
> > q.options(eagerload('otherprop')).select ( or_( A.c.something ==
> None, A.c.something == False ), from_obj = [A.outerjoin(B,and_(...some
> stuff...)] )
> The generated SQL has the following form in this case:
>
> FROM A LEFT OUTER JOIN B ON ... some stuff ... ,
> A LEFT OUTER JOIN <otherprop's table> ON ...whatever....
>
> As you can see, A is specified twice and the query fails with an
> SQLError being thrown. tried adding the table for the "otherprop" to
> the outerjoin in the from_obj but it looks like the eagerload option
> appends the whole new outerjoin regardless. (In the latter case I just
> got two duplicated tables in the from clause.)
>
> Anyway, I'm OK with having to add the tables,join conditions to the
> from_obj if that makes the most sense. (And I think to make q.select
> function correctly something does have to be available there.)
>
> A few places in my code, I use the select_by method instead of select.
> I've noticed it generates the correct sql to find properties on
> related tables. It seems this problem would be easier solved by
> adding "or" functionality to select_by and letting the join logic use
> what is already programmed.
>
> Something like q.select_by ( or_( prop1=This, prop1=That ) )
> (I know the or_ function works with a tables column definitions and is
> not dictionary like as is with the select_by method though.) One
> problem is that there doesn't seem to be a way to clarify which
> related table is used if more than one relation has the same property
> name. (It uses the first one it comes across by default.)
>
> Again, thanks for your attention to this. SQLAlchemy is becoming a
> very fine product.
>
> -Dennis
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
