On 9/18/15 7:58 PM, George Reilly wrote:
Thanks for the prompt answer. I tried after_cursor_execute, but it
didn't really help as I just got a tuple of the values, without a
clear way to associate them with the parameter names. Ultimately, I
found that the following gives me the best results:
named_params
= {}
for k,v in query_params.iteritems():
named_params[k] = v
if v is None:
label = text.binds[k]._identifying_key
for param_dict in multiparams:
if label in param_dict:
named_params[k] = param_dict[label]
break
Now I can identify which queries are being called repeatedly with
identical parameters; I couldn't before.
OK, you can also take a look at the "context" passed there, which has
the parameters in a consistent format, i think in .compiled_parameters.
Poke around it to see.
Changing topic somewhat, I find it frustrating that the session does
not cache queries.
"caching queries" is an ambiguous term. It could mean:
1. that we cache the production of the SQL string given a Query or
select() object. A lot of that kind of caching *does* go on behind the
scenes in the ORM's flush process, but if you want it for SELECT objects
via Query, we have BakedQuery for that:
http://docs.sqlalchemy.org/en/rel_1_0/orm/extensions/baked.html
2. that the results of an ORM query invocation are cached. This is a
simple feature to implement, but as a user, it gets confusing very fast,
considering that the ORM emits lots of different kinds of statements in
different situations, especially if you're looking to invalidate the
cache. For this reason, we ask that our users make an investment in
understanding the mechanics of query result caching, hence it is
available as an example suite, which you can see at Dogpile Caching:
http://docs.sqlalchemy.org/en/rel_1_0/orm/examples.html#module-examples.dogpile_caching
.
http://docs.sqlalchemy.org/en/rel_1_1/orm/session_basics.html#is-the-session-a-cache
makes it clear that this is deliberate, but I think that section could
benefit from further explanation about _why_ SQLAlchemy does not cache
queries.
This section refers explicitly to the fact that "caching queries" as you
refer to here is a "second level cache", and links to the above dogpile
example. The Session's caching is limited to transaction level identity
caching only.
Thanks,
/George
--
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
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
To post to this group, send email to sqlalchemy@googlegroups.com
<mailto:sqlalchemy@googlegroups.com>.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
