Yeah, I didn't include the whole Content mapper, here are the
polymorphic params for that mapper:
polymorphic_on=content_table.c.type, polymorphic_identity='content'
And ContentLeaf:
mapper(ContentLeaf, content_leaf,
properties = {
'_copyright': content_leaf.c.copyright,'copyright' :
synonym('_copyright'),
'_grid ': content_leaf.c.grid,'grid' :
synonym('_grid'),
'_gtin' : content_leaf.c.gtin,'gtin' :
synonym('_gtin'),
'_iswc' : content_leaf.c.iswc,'iswc' :
synonym('_iswc'),
'_isan' : content_leaf.c.isan,'isan' :
synonym('_isan'),
'_isrc' : content_leaf.c.isrc,'isrc' :
synonym('_isrc'),
'_reviewed' : content_leaf.c.reviewed,'reviewed' :
synonym('_reviewed'),
'_flagged' : content_leaf.c.flagged,'flagged' :
synonym('_flagged'),
'_ingestion_type':
content_leaf.c.ingestion_type,'ingestion_type' :
synonym('_ingestion_type'),
},
inherits = cm,
polymorphic_on = content_table.c.type,
polymorphic_identity ='leaf')
So, loading polymorphically is working for me.
So maybe I can do something like:
q =
Session.query(Content).add_entity(Account).select_from(content_table.outerjoin(accounts))
To get the account?
thx
m
On Dec 30, 2:53 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
> 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 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
-~----------~----~----~----~------~----~------~--~---
