On Dec 30, 2007, at 3:20 PM, Matt wrote:
>
> Hi all,
>
> I'm having an issue where I'm doing a query that I want to be loaded
> all in one select to the database. I have a table "ContentLeaf" which
> inherits from "Content", I can get the ContentLeaf fields to eagerload
> by using select_table in the mapper:
>
> myjoin = content_table.outerjoin(content_leaf)
> cm = mapper(Content, content_table,
> select_table = myjoin,
> properties = {
> 'account' : relation(Account, cascade='all',
> lazy=False),
I dont really understand what the desired behavior is here, unless you
are trying to load polymorphically - but I dont see any "polymorphic"
attributes on this mapper, so that won't work.
the mapper for Content will map attributes to each column in the
"content_table" table. when you specify
select_table=content_table.join(someothertable), the columns in
(someothertable) will be present in the result rows returned by the
database, but will have no impact whatsoever on the data which is
fetched from each row, since as far as I can tell nothing is mapped to
the "content_leaf" table. if content_leaf is mapped to some other
class, the Content mapper above still does not have any polymorphic
attributes configured so its still not going to have any effect on
what gets returned. so the "select_table" argument is really
meaningless when used with a mapper that has no polymorphic options
configured. if you need to load more than one kind of object from a
select or a join, theres other ways to do that, discussed below.
>
>
> Here I also define the account property to eagerload by specifying
> lazy=False. In this case, only the ContentLeaf eagerloads and I see
> this in the debug logs:
So heres the next side effect of "select_table" - which is that eager
loading relations are not currently get included when you load from a
select_table. Usually, select_table is used for a polymorphic "all at
once" load of a hierarchy of classes, so the joins issued are already
fairly complex. We will eventually have select_table loads include
the eagerloading of relations attached to the base mapper, possibly in
0.4.3. But in this case i dont think select_table is what youre
looking for unless theres some other detail missing here.
>
> If I remove the select_table, the account property will then
> eagerload, but I really want both to eagerload in the same query. Any
> ideas on how to make this happen?
So, im assuming that you have some other class mapped to
content_leaf. Depending on how you have your ContentLeaf (or
whatever its called) class related to Content would determine what to
use. Theres four general patterns you might use. one is inheritance:
mapper(Content, content_table,
polymorphic_on=content_table.c.type, polymorphic_identity='content')
mapper(ContentLeaf, content_leaf, inherits=Content,
polymorphic_identity='content_leaf')
another is eagerloading relation():
mapper(Content, content_table, properties={
'leafs':relation(ContentLeaf, lazy=False),
'account':relation(Account, lazy=False)
})
or you'd just like an ad-hoc join that loads both - this might be what
youre looking for in this case:
results =
session
.query
(Content
).add_entity
(ContentLeaf).select_from(content_table.outerjoin(content_leaf)).all()
the "results" would be a list of tuples in the form (Content(),
ContentLeaf()). with the above query the eager load from "Content" to
"account" should work as well...if not, use the trunk which will be
released as 0.4.2 in the next few days since we've made some
improvements to this area.
Theres also the possibility that you just want Content mapped to both
tables; thats doable as well, except you still wouldnt use
select_table, you'd just map to the join directly:
mapper(Content, content_table.outerjoin(content_leaf),
properties={...})
so if you still cant fit your use case here, provide a more detailed
example of what your classes look like and how youd like them mapped
to each table.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
