[sqlalchemy] Re: multiple mappers on une table problem.
On 6/11/07, Michael Bayer [EMAIL PROTECTED] wrote: secondly: a non-primary mapper is just an awkward way of defining an ORM query. Since we support generative queries now, you can just make a Query object with the criterion youre looking for and just hold onto it...youre just adding a single WHERE criterion, so my_secondary_query = query(MyClass).filter(table.c.tipo=='p'). much easier. ideally Query should be replacing 90% of all non_primary mapper use cases. So in your mind, is my non-primary example over at http://spyced.blogspot.com/2007/01/why-sqlalchemy-impresses-me.html part of the other 10%? I don't think holding onto a query is as elegant as being able to say user.max_order in a eager or lazy context and having that Just Work, but maybe I am missing something. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: multiple mappers on une table problem.
On Jun 19, 2007, at 1:43 PM, Jonathan Ellis wrote: On 6/11/07, Michael Bayer [EMAIL PROTECTED] wrote: secondly: a non-primary mapper is just an awkward way of defining an ORM query. Since we support generative queries now, you can just make a Query object with the criterion youre looking for and just hold onto it...youre just adding a single WHERE criterion, so my_secondary_query = query(MyClass).filter(table.c.tipo=='p'). much easier. ideally Query should be replacing 90% of all non_primary mapper use cases. So in your mind, is my non-primary example over at http://spyced.blogspot.com/2007/01/why-sqlalchemy-impresses-me.html part of the other 10%? I don't think holding onto a query is as elegant as being able to say user.max_order in a eager or lazy context and having that Just Work, but maybe I am missing something. your blog post is the other 10% :) pretty much, the only time non-primary mapper provides anything that Query currently does not is if you make a relationship *to* the non- primary mapper. however, it would be nice to totally get rid of non-primary mappers because they are usually the wrong path to take, and they are so much like a Query.ideally, mappers shouldnt have anything to say about how its loaded, just how its represented in the database. (this is why i like our low version numbers. if we ever get to the 0.7s, 0.8s etc. these roles would hopefully be rock solid). the only thing you are getting in your particular example is the ability for the relationship to get bundled into an eager load. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: multiple mappers on une table problem.
On Jun 11, 2007, at 11:12 AM, Glauco wrote: This cause a lot of inspiegable problem to property that are perfecly functional in the primary sqlalchemy.exceptions.ArgumentError: Can't determine relation direction for relationship 'Blabla.comune_nascita (Comune)' - foreign key columns are present in neither the parent nor the child's mapped tables you need to explicitly specify conditions like primaryjoin, foreign_keys, etc. http://www.sqlalchemy.org/docs/ adv_datamapping.html#advdatamapping_properties_customjoin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: multiple mappers on une table problem.
Michael Bayer ha scritto:
On Jun 11, 2007, at 11:12 AM, Glauco wrote:
This cause a lot of inspiegable problem to property that are perfecly
functional in the primary
sqlalchemy.exceptions.ArgumentError: Can't determine relation
direction
for relationship 'Blabla.comune_nascita (Comune)' - foreign key
columns
are present in neither the parent nor the child's mapped tables
you need to explicitly specify conditions like primaryjoin,
foreign_keys, etc.
http://www.sqlalchemy.org/docs/
adv_datamapping.html#advdatamapping_properties_customjoin
For this reason i've inserted explicit primaryjoin condition, and these
condition work perfectly in the primary mapper.
But in the secondary wont work...
class Anagrafica:
bla bla
# my primary mapper
assign_mapper(context,
Anagrafica,
tbl['anagrafica'],
column_prefix = 'anagrafica_',
extension = SelectResultsExt(),
properties = {
'comune' : relation( Comune,
primaryjoin = tbl['anagrafica'].c.id_comune ==
tbl['comune'].c.id ),
'nazione': relation( Nazione,
primaryjoin = tbl['anagrafica'].c.cod_nazionalita ==
tbl['nazione'].c.codice ),?
'comune_nascita' : relation( Comune,
primaryjoin = tbl['anagrafica'].c.id_comune_nascita
== tbl['comune'].c.id),
'nazione_nascita' : relation(Nazione,
primaryjoin = tbl['anagrafica'].c.cod_nazione_nascita
== tbl['nazione'].c.codice ),
'professione': relation( Professione ),
'titolo_studio' : relation( TitoloStudio ),
})
# my secondary mapper
class Person( Anagrafica ):
pass
assign_mapper(context,
Person,
select([tbl['anagrafica']], tbl['anagrafica'].c.tipo ==
'P').alias('person'),
column_prefix = 'anagrafica_',
extension = SelectResultsExt(),
non_primary = True,
properties = {
'comune' : relation( Comune,
primaryjoin = tbl['anagrafica'].c.id_comune ==
tbl['comune'].c.id ),
'nazione': relation( Nazione,
primaryjoin = tbl['anagrafica'].c.cod_nazionalita ==
tbl['nazione'].c.codice ),?
'comune_nascita' : relation( Comune,
primaryjoin = tbl['anagrafica'].c.id_comune_nascita
== tbl['comune'].c.id),
'nazione_nascita' : relation(Nazione,
primaryjoin = tbl['anagrafica'].c.cod_nazione_nascita
== tbl['nazione'].c.codice ),
'professione': relation( Professione ),
'titolo_studio' : relation( TitoloStudio ),
})
In [8]: Anagrafica.search()
Out[8]: sqlalchemy.ext.selectresults.SelectResults object at 0xb6dfa92c
In [9]: Person.search()
ArgumentError: Can't determine relation direction for relationship
'Person.comune_nascita (Comune)' - foreign key columns are present in
neither the parent nor the child's mapped tables
Some ideas?
Thank you
Glauco
--
++
Glauco Uri - Programmatore
glauco(at)allevatori.com
Sfera Carta Software(r) [EMAIL PROTECTED]
Via Bazzanese,69 Casalecchio di Reno(BO) - Tel. 051591054
++
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: multiple mappers on une table problem.
On Jun 11, 2007, at 12:21 PM, Glauco wrote:
For this reason i've inserted explicit primaryjoin condition, and
these condition work perfectly in the primary mapper.
But in the secondary wont work...
theres many reasons why you probably dont want to do what youre
trying to do.
first off, adding relations to a non-primary mapper: the class still
will lazy load relationships from the primary mapper, since they are
invoked from attributes. it doesnt entirely make sense to add
relationships to a secondary mapper for this reason - the
relationships will only take effect from the secondary mapper if you
are using eager loading. and in that case, we dont really have any
test cases for that so i cant say how well its going to work.
secondly: a non-primary mapper is just an awkward way of defining an
ORM query. Since we support generative queries now, you can just
make a Query object with the criterion youre looking for and just
hold onto it...youre just adding a single WHERE criterion, so
my_secondary_query = query(MyClass).filter(table.c.tipo=='p'). much
easier. ideally Query should be replacing 90% of all non_primary
mapper use cases.
thirdly: it doesnt make much sense to use assign_mapper() with a
secondary mapper, since thats not the mapper which the class is
primarily associated with.
So after all that, if you still want to get it to work, you need the
primaryjoin criterion to be against the mapped selectable:
myselect = select[mytable]).alias('myselect')
mapper(MyClass, myselect, non_primary=True, properties={
'stuff': relation(OtherClass,
primaryjoin=myselect.c.id==othertable.c.myid)
})
you also may need to add the foreign_keys=[cols] parameter which
will identfify which columns in the join conditions are foreign, if
SA cannot figure out what they are.
mapper(MyClass, myselect, non_primary=True, properties={
'stuff': relation(OtherClass,
primaryjoin=myselect.c.id==othertable.c.myid, foreign_keys=
[othertable.c.myid])
})
hope this helps...good luck
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
