On Saturday, September 19, 2015 at 8:14:31 AM UTC-7, Michael Bayer wrote:
>
>
>
> 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.
>
Ah, that made it simpler.
def _extract_parameters_from_results(self, query_results):
params_dict = {}
for p in getattr(query_results.context, 'compiled_parameters', []):
params_dict.update(p)
return params_dict
> 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>
> 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.
>
>
Fair enough. 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.
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.
