one more point that i forgot to mention in the workflow, so i re-wrote it
again:
- search request comes
- if orm mapping is not created it's get created now (only happens one time)
- new session is created using orm.create_session(weak_identity_map=True).
now this new session is added to a python dict like this:
resources = {
SESSION: session
OTHER_RESOURCE: obj
}
and then this resources dict is attached to the current request thread (this
is done so that different DAOs can access the same session and other
resources from the current thread).
- all orm queries are fired.. results processed
- finally, current thread is accessed again and tear down happens as below:
resources = currentThread().resources
resources[SESSION].clear()
del resources
my question is that i am deleting resources dict but not resources[SESSION]
(session object) which might be being pointed to by sa data structure
associated as a part of initial orm.create_session call? i have not done a
deep dive in sa source code but just guessing.
On Wed, Jun 18, 2008 at 8:57 PM, Michael Bayer <[EMAIL PROTECTED]>
wrote:
>
>
> On Jun 18, 2008, at 11:17 AM, Arun Kumar PG wrote:
>
> > one more thing here, i noticed now that the query formed by sa when
> > we do an eager load has got some problems (may be i am not doing the
> > right thing)
> >
> > here's the problem
> >
> > i have entities A, B. where A -> B (1:N relationship)
> >
> > i form a query like this
> >
> > clauses = []
> > clauses.append(A.c.col1 == 'xyz')
> > clauses.append(B.c.col == 'xcv')
> >
> > qry = session.query(B).filter_by(*clauses)
> > eager_qry = qry.options(sqlalchemy.eagerload('a')
> > eager_qry.all()
> >
> > the sql shows:
> >
> > select ... from A, B left outer join A as alias on alias.key == B.key
> >
> > why is A included for join two times ? i understand eager load might
> > be creating the outer join but looks like because i am having a
> > clause on A, A is included in the first join as well.
> >
> > what is the right way to use it so that i can get rid off first join
> > and eager load A.
> >
> > this is creating a huge result set.
>
>
> the joins created by eager loading are insulated from anything you do
> with filter(), order_by(), etc. This is so that your collections load
> properly even if criterion were applied that would otherwise limit the
> collection from loading fully.
>
> See
> http://www.sqlalchemy.org/trac/wiki/FAQ#ImusinglazyFalsetocreateaJOINOUTERJOINandSQLAlchemyisnotconstructingthequerywhenItrytoaddaWHEREORDERBYLIMITetc.whichreliesupontheOUTERJOIN
> .
>
> You have two options here: either use an explicit join in your query,
> so that the Query works regardless of the eager loading being present
> or not. Or, if you truly want the eager loaded collection to reflect
> the query criterion, instead of using "eagerload" you can use
> "contains_eager", as described in
> http://www.sqlalchemy.org/docs/05/mappers.html#advdatamapping_relation_strategies_containseager
> . Those are the 0.5 docs but the same technique applies to the most
> recent 0.4 version.
>
>
>
> >
>
--
cheers,
- a
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
