Re: [sqlalchemy] passing parameters to subquery in mapped select

2011-10-14 Thread Michael Bayer

On Oct 14, 2011, at 10:56 AM, Burak Arslan wrote:

 On 10/14/11 06:40, Michael Bayer wrote:
 its a little awkward but if you use bindparam() in the inner select, 
 query.params() can access those parameters just fine, you'd just need to use 
 it in all cases.
 
 there's some related example of doing this with a relationship at 
 http://www.sqlalchemy.org/trac/wiki/UsageRecipes/GlobalFilter .
 
 hi michael,
 
 thank you very much for the reply, your suggestion solves my issue.
 however, I do agree that it's a little bit awkward to have to remember a
 params() after a .filter(), is there any reason for not unifying them?

how would a unification of filter() and params() look ?

filter() expresses expression structures, and params() the values.   You can 
use just filter() with literal values and they are converted into bind params 
automatically.

just not clear what you mean here.



-- 
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.



Re: [sqlalchemy] passing parameters to subquery in mapped select

2011-10-14 Thread Burak Arslan
On 10/14/11 18:01, Michael Bayer wrote:
 On Oct 14, 2011, at 10:56 AM, Burak Arslan wrote:

 On 10/14/11 06:40, Michael Bayer wrote:
 its a little awkward but if you use bindparam() in the inner select, 
 query.params() can access those parameters just fine, you'd just need to 
 use it in all cases.

 there's some related example of doing this with a relationship at 
 http://www.sqlalchemy.org/trac/wiki/UsageRecipes/GlobalFilter .
 hi michael,

 thank you very much for the reply, your suggestion solves my issue.
 however, I do agree that it's a little bit awkward to have to remember a
 params() after a .filter(), is there any reason for not unifying them?
 how would a unification of filter() and params() look ?

 filter() expresses expression structures, and params() the values.   You can 
 use just filter() with literal values and they are converted into bind params 
 automatically.

 just not clear what you mean here.



I mean, currently my query looks like this:

query(SomeTable).filter_by(some_column=some_val).params(some_other_col=some_other_val)

I'd prefer:

query(SomeTable).filter_by(some_column=some_val,
some_other_col=some_other_val)

that's not much of a hassle to be honest, but i'm just curious.

thanks,
burak


-- 
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.



Re: [sqlalchemy] passing parameters to subquery in mapped select

2011-10-13 Thread Michael Bayer
its a little awkward but if you use bindparam() in the inner select, 
query.params() can access those parameters just fine, you'd just need to use it 
in all cases.

there's some related example of doing this with a relationship at 
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/GlobalFilter .


On Oct 13, 2011, at 6:39 PM, Burak Arslan wrote:

 hi,
 
 is there a way to pass a parameter to a subquery inside a select mapped
 to a class? the generated query looks like this:
 
 select * from (
select distinct on (some_table.id) some_table.id, ... from
 some_table where some_condition
 ) as v join ...
 
 the outer select is mapped to a class, but when i try to query on that
 class, the conditions are naturally applied to the outer query. because
 of distinct in the subquery, i get random results. i need to put
 conditions on the inner query. (and yes, I do need that distinct in
 there. i can't put it to the outer query because that messes with order
 by. i can't use group by because not all columns respond to aggregates.)
 
 should I just drop the orm for this specific case?
 
 thanks,
 burak
 
 -- 
 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.
 

-- 
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.