On Jun 6, 2013, at 1:03 PM, Claudio Freire <klaussfre...@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 5:26 PM, Claudio Freire <klaussfre...@gmail.com> wrote:
>> On Sun, Jun 2, 2013 at 9:41 PM, Claudio Freire <klaussfre...@gmail.com>
>> wrote:
>>>>
>>>> So the whole thing is rolled up into the "named" thing I referred to
>>>> also, so that there's no need to keep a Query object hanging around, when
>>>> we
>>>> say "bake()" we're really just referring to a position in the code
>>>> somewhere, so I've updated the wiki recipe to use a named system like this:
>>>>
>>>> q = s.query(Foo).\
>>>> filter(Foo.data == bindparam('foo')).\
>>>> bake_as("foo", cache)
>>>> result = q.params(foo='data 12').all()
>>>>
>>>>
>>>> A highly cleaned up version of your test is attached.
>>>>
>>>> I'm still not sure I'm getting everything accounted for here! thanks for
>>>> testing ! The feature is actually looking quite simple and probably works
>>>> better as something built in, or at least if we added some methods to
>>>> QueryContext to ease the burden of caching/copying it.
>>>
>>>
>>> Well, if that works, it certainly covers my needs so there would be no
>>> pressing need to incorporate it into the core.
>>> I'll let you know tomorrow.
>>
>>
>>
>> I've done only superficial testing for now, I have to build me a test
>> database, but I thought I'd let you know, it seems to work flawless till
>> now.
>
>
> Seems to break unpredictably with subqueryloads.
>
> I'll try to get a test for it.
I think I know why that might be, because subqueryload is using that same query
to build a new one. the new one still has the wrong _baked_context stuck on
it.
So one way to fix would be to hack into the recipe to blow away the
"_baked_context" when subqueryload starts working with the query. Really,
"_baked_context" should be automatically blown away for all generative methods
except for params() and maybe some others. We should add some logic to
_clone() and _generative() to control this (see below).
But that starts defeating the purpose of the baking. So really, this starts
looking like the actual feature - the Subqueryloader would want to detect this
"baked" condition, and then "bake" the query that it makes as well, using the
original "baked" name appended with the "loader path" that it's working with.
See now that is starting to make this look cool (but we've gone into, "this is
a built in feature now" territory).
diff --git a/lib/sqlalchemy/orm/query.py b/lib/sqlalchemy/orm/query.py
index c2ec72c..b458975 100644
--- a/lib/sqlalchemy/orm/query.py
+++ b/lib/sqlalchemy/orm/query.py
@@ -40,12 +40,15 @@ from ..sql import (
__all__ = ['Query', 'QueryContext', 'aliased']
-def _generative(*assertions):
+def _generative(*assertions, maintain_baked=False):
"""Mark a method as generative."""
@util.decorator
def generate(fn, *args, **kw):
self = args[0]._clone()
+ if not maintain_baked:
+ del self._baked_cache
+ del self._baked_context
for assertion in assertions:
assertion(self, fn.func_name)
fn(self, *args[1:], **kw)
@@ -1157,7 +1160,7 @@ class Query(object):
self._lockmode = mode
- @_generative()
+ @_generative(maintain_baked=True)
def params(self, *args, **kwargs):
"""add values for bind parameters which may have been
specified in filter().
--
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.
