here is why this feature will create more surprise bugs and user
confusion than its worth, and why i dont really want to get into it
(a user contributed extension/wiki recipe being a preferable
candidate for this kind of thing ):
class Foo(object):pass
class Bar(Foo):pass
class Lala(object):pass
# Lala mapper
mapper(Lala, lala_table)
# Foo mapper. polymorphic (i.e. loads Foos and Bars in one query),
contains a relation to Lala.
foomapper = mapper(Foo, foo_table,
polymorphic_on=foo_table.c.foo_type, polymorphic_identity='foo',
properties={
'lalas':relation(Lala)
})
# Bar mapper. single-table inherits from Foo, includes its own
relation to Lala.
mapper(Bar, None, inherits=Foo, polymorphic_identity='bar',
properties={
'extra_lalas' : relation(Lala)
})
# Foo mapper now contains a child relationship of "bars" as well, so
theres Lala's attached to Foo in
# three different ways now: directly, polymorphically, and via each
"Bar" item on its "bars" relationship.
foomapper.add_property('bars' :relation(Bar, secondary=bar_foos))
query = session.query(Foo)
query.select_with_auto_join(lala_table.c.data == 'hi')
So now im asking for all Foos (and Bars) where a related column in
"lala_table" equals "hi". What query should that produce ?
On May 8, 2006, at 3:26 PM, Sandro Dentella wrote:
1. why the implicit behaviour of select_by (ie: join) isn't the
default
of a mapper that was already prepared to be a join? As I told
in a
prevuous message and if I undertsand it correctly this leads
to a CROSS
JOIN that is probably not what anybody looks for...
because explicit is better than implicit. if you had multiple
I mean implicit in the select, not in the mapper!
relations against the same table, inheritance relationships against
the same table to which you have attribure relations, etc., its not
clear at all how it should implicitly "decide" what joins to create.
looking at which relations where used to create the mapper... as
select_by
does...
2. alternatively: why can't I use limit= and parameters= for
select_by?
because every keyword argument passed to select_by is part of the
criterion being used. select_by is only meant to be a shortcut in a
narrow range of situations (although its a very common situation).
w/o limit and params= it's possibly even narrower... but you admit
it's a
very common situation... may I hope you will add those parameters?
TIA
sandro
*:-)
--
Sandro Dentella *:-)
e-mail: [EMAIL PROTECTED]
http://www.tksql.org TkSQL Home page - My GPL work
-------------------------------------------------------
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
