On Apr 9, 12:19 pm, "Michael Bayer" <[email protected]> wrote:
> mdoar wrote:
>
> > I'm using declarative classes for a table with a few foreign keys to
> > other tables. When I look at the SQL queries I see the query to get
> > all the rows of the main table and then a few extra queries for each
> > row's foreign keys; all as expected. However, it seems that since I am
> > not modifying any of the tables, there might be a way to have the
> > secondary tables loaded once to avoid the multiple queries per row
> > that is killing performance right now.
>
> > Am I missing some option that already exists?
>
> the many-to-one loads will place those entities in the session keyed to
> their primary key. when a lazyloader on a parent object fires off, it
> checks the identity map first before loading. So as long as that object
> was already loaded and is strongly referenced, it wont use SQL.
Makes sense. Since I'm using reflection and declarative, I have code
like
aTable = Table(tablename, Base.metadata,
Column('dbid', primary_key=True),
Column('state', index=True),
useexisting=True)
....
clz = type(classname, (Base,), {'__table__' : aTable})
and then define a relation later on with:
Defect.stateObj = orm.relation(Statedef,
primaryjoin=Defect.state==Statedef.id,
foreign_keys=
[Statedef.__table__.columns['id'] ])
>
> Here's what is needed for that to work.
>
> 1. strongly referenced somewhere, or weak_identity_map=False on your
> session. else the object is garbage collected and SQL is required to load
> it.
weak_identity_map=False is the default. Looking at the documentation,
perhaps you meant "weak_identity_map=True"?
> 2. the relation is many-to-one and would use the same SQL to load as that
> of a query.get(). For simple many-to-ones this always the case, but in
> the case of custom primaryjoin conditions or with some inheritance
> scenarios, its not. If your many-to-one references a column on a
> joined-table inheriting class, specify a custom primaryjoin that
> references the primary key column(s) on the base table - you'll need the
> foreign_keys argument for this too.
>
>
I have an explicit primaryjoin as shown above but it sounds like this
should still hold?
~Matt
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
