On Jul 13, 2013, at 11:27 AM, Amir Elaguizy <aelag...@gmail.com> wrote:
> Awesome Michael it has given a speedup actually outside of caching even,
> which is great.
>
> How do I do the equivelant of this though?
>
> compiled = stmt.compile()
> params = compiled.params
>
> # here we return the key as a long string. our "key mangler"
> # set up with the region will boil it down to an md5.
> return " ".join(
> [str(compiled)] +
> [str(params[k]) for k in sorted(params)])
>
> I have the baked query context in the cache, and getting a string statement
> from that is easy. How do I get the parameters out, to use as unique
> identifiers?
you mean the names ? you'd have to scan the whole query for them, we used to
use this in the "caching" recipe so maybe build on this idea (note it's not
complete, you might want to traverse all of query.statement):
def _params_from_query(query):
"""Pull the bind parameter values from a query.
This takes into account any scalar attribute bindparam set up.
E.g. params_from_query(query.filter(Cls.foo==5).filter(Cls.bar==7)))
would return [5, 7].
"""
v = []
def visit_bindparam(bind):
if bind.key in query._params:
value = query._params[bind.key]
elif bind.callable:
# lazyloader may dig a callable in here, intended
# to late-evaluate params after autoflush is called.
# convert to a scalar value.
value = bind.callable()
else:
value = bind.value
v.append(value)
if query._criterion is not None:
visitors.traverse(query._criterion, {}, {'bindparam':visit_bindparam})
for f in query._from_obj:
visitors.traverse(f, {}, {'bindparam':visit_bindparam})
return v
>
> Thanks!
> Amir
>
> On Friday, July 12, 2013 4:53:37 PM UTC-7, Michael Bayer wrote:
>
> On Jul 12, 2013, at 7:03 PM, Amir Elaguizy <aela...@gmail.com> wrote:
>
> > I'd like a way to avoid the cost of repeatedly compiling the same query,
> > especially in the context of relationship caching.
> >
> > Specifically now that I have object caching in place, I have created my own
> > keys where it is possible. However there are still some cases where I
> > cannot. In these cases I'm falling back to the query based key mechanism:
> >
> > stmt = query.with_labels().statement
> > compiled = stmt.compile()
> > params = compiled.params
> >
> > However this is incredibly slow and what I'm finding is that I'm paying the
> > cost for compiling the same query with just the parameters themselves
> > changing. I'd like to create an in memory query cache in which the compiled
> > queries are stored and the parameters are switched out, or something like
> > that.
>
> See the recipe at http://www.sqlalchemy.org/trac/wiki/UsageRecipes/BakedQuery
> which will get you most of the way there, and there are plans at some point
> to make this into a fully supported feature.
>
>
>
> --
> 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/groups/opt_out.
>
>
--
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/groups/opt_out.
