select_by should be able to handle going as deep as it goes. You
cant put a > in there since select_by is just taking python keyword
arguments. We also cant use select(), since that expects the full
criterion, i.e. its the generalized case that lets you do anything.
so right off thats another method to add, and we've already had some
grumbling about "too many methods that do the same thing".
the other thing is that I can see a feature like this screwing up a
large percentage of the time, which is something I shy away from when
theres an explicit version people can use (and therefore theyll fix
their own screwup instead of adding to my workload...people submit
bugs all the time and their test programs dont even echo the SQL
output, indicative of their lack of curiousity....).
why not start off by writing your own function to loop through the
mappers, look at their "primaryjoin" and "secondaryjoin"
attributes ? i.e.
pj = mapper.props['key'].primaryjoin
sj_2 = mapper.props['key1'].mapper.props['key2'].secondaryjoin
On May 4, 2006, at 3:10 PM, Randall Smith wrote:
One feature that caught my attention when I first started using
sqlalchemy was this example:
l = User.mapper.select_by(street='123 Green Street')
This is in the section entitled 'Useful Feature: Creating Joins via
select_by' and it touches on something I think is severely needed.
If you're going to go to all the trouble to define relationships in
your model, why should you need to redefine them when you query the
data. As far as I can tell, this doesn't work past the first
relation ship (am I wrong?), but is there a reason it can't?
I'll give an example. I work with drinking water samples. The
relationship between a Water System and Sample Result looks like this:
Water System -> Facility -> Sampling Point -> Sample -> Result
So say I want to know which water systems had high lead levels
sampled after January.
This should be possible like so:
high_systems = WaterSystem.select_by(Sample.c.date_collected >
'2006-01-01',
Result.value > max_value)
I'm not saying this is the correct syntax. What I am saying is
that sqlalchemy already knows how these tables are related to each
other, so I should not have to create an explicit join for the query.
What do you think? Are there technical reasons this can't work?
Randall
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?
cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
