yeah...this is totally fine for you to use, but i dont want to change
SA to this, particularly becuase it forces a change to the return
signature of join_via...it makes an arbitrary alias, and returns
three objects back to you which now you have to use in the criterion,
trust me nobody's g
final, ok for indirect recursion too .
##
import sqlalchemy
def join_via( keys, mapper):
'''Query.join_via, input root mapper, return last mapper/table;
alias and link properly recursive /self-referential joins
'''
clause = None
c = None
self_table = None
Here, no need to touch Property.get_join(), only a new join_via():
def join_via( keys, mapper):
clause = None
c = None
self_select_table = None
for key in keys:
prop = mapper.props[key]
try:
c = prop.get_join() #SA rev<2285
except TypeEr
no, wrong, there's more to it; each level's parent.table should be the
previous level's aliased table...
> i think i managed to construct a proper thing, changing
> PropertyLoader.get_join(), and made my own join_via():
--~--~-~--~~~---~--~~
You received this mes
> > heh, i don't have a vague idea what it should be.
>
> because you dont want to learn SQL. but if youre really trying to
> write a one-person system on the scale of complexity of SAP, which
> usually have...i dunno, several hundred developers for many years ?
> i think youre gonna have to.
le
On Feb 15, 2007, at 10:41 AM, svilen wrote:
> heh, i don't have a vague idea what it should be.
because you dont want to learn SQL. but if youre really trying to
write a one-person system on the scale of complexity of SAP, which
usually have...i dunno, several hundred developers for many
> havent pored through any of these, but keep in mind you dont need
> to use the query building feature at all. you can send your own
> full- blown SQL if you have a better idea of what query should be
> used for a particular case (using either query.instances() or by
> sending a full select() co
havent pored through any of these, but keep in mind you dont need to
use the query building feature at all. you can send your own full-
blown SQL if you have a better idea of what query should be used for a
particular case (using either query.instances() or by sending a full
select() construct to
and, how u make the (3) or (4) work?
aliasing the table.column in the comparison does not help.. it should
be aliased somehow inside the join also..
Here a simpler case, without the inheritance.
3 and 4 do not work here too - one does exception, other return
nothing.
maybe express the query
can i make the mapper.someproperty.get_join() to return aliased
version somehow? maybe copy the mapper?
> taking a look, i think what you should do is use an alias of the
> table_Employee in your queries. since the engineer mapper is using
> joined table inheritance, the default table_Employee
on the way of programaticaly constructing (2) - actualy like (4) is
done internaly, it looks to me maybe Property.get_join( parent) can
be hinted somehow.. e.g. in case of only-table_inheritance, using the
base table would be enough. Maybe i can just change the parent mapper
to the simple non-
> taking a look, i think what you should do is use an alias of the
> table_Employee in your queries. since the engineer mapper is using
> joined table inheritance, the default table_Employee is already
> going to be involved in the query, so your external join condition
> needs to be off a disti
taking a look, i think what you should do is use an alias of the
table_Employee in your queries. since the engineer mapper is using
joined table inheritance, the default table_Employee is already going
to be involved in the query, so your external join condition needs to
be off a distinct alias o
THANK YOU for the nice test case that does not require untarring 35
files ! sorry for pushing more of the effort off. ill take a look at
this later today.
On Feb 13, 11:17 am, svilen <[EMAIL PROTECTED]> wrote:
> hi.
>
> Here is a simple case which does not work - or i cannot figure out how
> to
14 matches
Mail list logo
