No, what you have will work as expected.
On Saturday, 8 September 2012 17:02:00 UTC-5, rochacbruno wrote:
>
> I am using:
>
> cache_key = "%s_%s_%s" % (query, start, end)
> total, rows = cache.ram(cache_key, lambda: (db(query).count(),
> db(query).select(limitby=(start, end), cacheable=True)), 36
El sábado, 8 de septiembre de 2012 17:47:49 UTC-3, Massimo Di Pierro
escribió:
>
> In trunk. Could you check it?
>
Works fine!
Jose
--
I am using:
cache_key = "%s_%s_%s" % (query, start, end)
total, rows = cache.ram(cache_key, lambda: (db(query).count(),
db(query).select(limitby=(start, end), cacheable=True)), 3600)
Should I put a dummy cache=(...) just to have the benefits?
--
In trunk. Could you check it?
On Saturday, 8 September 2012 15:40:37 UTC-5, Jose wrote:
>
>
>
> El sábado, 8 de septiembre de 2012 16:47:56 UTC-3, Anthony escribió:
>>
>> I'd say, when cacheable=True and cache!=None, then cache the entire Rows
>> object (new behavior). However, if cacheable=False
El sábado, 8 de septiembre de 2012 16:47:56 UTC-3, Anthony escribió:
>
> I'd say, when cacheable=True and cache!=None, then cache the entire Rows
> object (new behavior). However, if cacheable=False, then revert to the old
> caching behavior (which should be the default).
+1
--
I'd say, when cacheable=True and cache!=None, then cache the entire Rows
object (new behavior). However, if cacheable=False, then revert to the old
caching behavior (which should be the default).
Anthony
On Saturday, September 8, 2012 1:22:32 PM UTC-4, Massimo Di Pierro wrote:
>
> What do other
I don't understand (ckickin?)
It should be optional and it shouldn't default to current behavior as it
breaks old apps.
On Sat, Sep 8, 2012 at 7:22 PM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:
> What do other people think? We can make the new behavior optional and only
> ckickin wh
What do other people think? We can make the new behavior optional and only
ckickin when both cache!=None and cacheable=True.
Massimo
On Saturday, 8 September 2012 09:20:24 UTC-5, Anthony wrote:
>
> Does this break backward compatibility? If so, should we make caching the
> full Rows object
Does this break backward compatibility? If so, should we make caching the
full Rows object an option (maybe just via the new "cacheable" argument)?
Anthony
On Saturday, September 8, 2012 10:06:56 AM UTC-4, Massimo Di Pierro wrote:
>
> Short answer:
>
> if you cache the select, subqueries are mis
Short answer:
if you cache the select, subqueries are missing. So you have to replace
email = row.emails.select().first()
with
email = db(db.emails.studio==row.id).select().first()
This is probably the only change of behavior and it is due to the need of
speedup. before cache was caching v
10 matches
Mail list logo
