I know this has been discussed a great deal already, but I've been
noticing this:

SomeClass.query()
    .filter_by(id = blah)
    .execution_options(compiled_cache = _orm_query_cache)
    .options(
         orm.joinedload(blah),
         orm.joinedload(blah, bleh),
         orm.joinedload(blah, bleh, blih),
         orm.joinedload(blah, bleh, blih, bloh),
     ).first()

It adds one entry in _orm_query_cache each time I run it.

The cache is a dict-like LRUCache object I intend to have in the
running application to avoid recompiling queries all the time. I've
also tried it like this:

_some_query = SomeClass.query()
    .filter_by(id = bindparam("bleh"))
    .execution_options(compiled_cache = _orm_query_cache)
    .options(
         orm.joinedload(blah),
         orm.joinedload(blah, bleh),
         orm.joinedload(blah, bleh, blih),
         orm.joinedload(blah, bleh, blih, bloh),
     )

globally, and in my hot function:

_some_query.with_session(session).params(bleh = bleh).first()

Both ways behave the same with regard to the cache. It will be in a
very hot path, I know compilation CPU usage pales in comparison with
the roundtrip, but since this is such a hot path, I expect compiling
repeatedly to be troublesome:

I expect to have an unholy amount of concurrency (in the order of 10k
rps), I don't want a few of these compiling bogging even minutely
other concurrent transactions, the application has very stringent
latency requirements, and even a small hiccup would be unacceptable.

I'm on latest 0.7, also tried 0.8. I tried the baked query recipe, and
it raises exceptions everywhere. I tried to patch it up, and it didn't
work (it would cache results as well which was really unintended).

But never mind baked query's brokenness, from what I've seen, and read
in other threads in the archive, the problem is queries are appended
to the cache by object identity. I'm thinking it wouldn't be hard
making the Query object hasheable, or at least adding a "bake()"
method that freezes it for hashing (prohibits hash-changing
alterations?).

That way, one could use the second form up there and benefit from
query hashing, because session/param binding wouldn't change the hash,
and it would be a cache hit. Has it been explored already? Or maybe
there's something wrong on how I'm using the compiled_cache thing?
Should I start patching? ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to