Thanks, that makes sense. In that context, I have two questions:
1. How do I call "cache.ram.clear" from outside web2py. What web2py
modules should I include?
2. How can I call a controller disguised as a user? I think this would
be the most robust way, if it is possible ...
On Friday, January 11, 2013 2:42:37 PM UTC+1, Niphlod wrote:
>
> Cache is always "related" to a key. In your function, that key is request.
> env.path_info
> Let's assume your key is "*the_key*"
> If you need to "invalidate" the cache, you should use cache.ram.clear("*
> the_key*") or cache.ram("*the_key*", None). From here one, there are 2
> paths ahead of you:
> - you have an empty cache and it will be filled at the 1st request coming
> from an user after you called clear()
> - you want to fill that key after clear() ASAP
>
> In the 1st case, after calling clear() you don't have to do nothing.
>
> In the 2nd case, either you call the controller "disguised as a user" or
> you process the data and store it using cache.ram("*the_key*", thevalue)
>
> Il giorno venerdì 11 gennaio 2013 13:07:08 UTC+1, Daniel Gonzalez ha
> scritto:
>>
>> Hi,
>>
>> I am serving some data which is expensive to compute with
>> a @service.jsonrpc controller. I want to cache the result in RAM, using
>> something like:
>>
>> @cache(request.env.path_info,time_expire=1000,cache_model=cache.ram)
>>
>> My data will not change very often, so I want to have a big ttl
>> (actually, I would like a ttl "forever", is this possible?)
>>
>> But my main problem is this: in my architecture, web2py does not know
>> when new data is available (the data is in a third-party database,
>> completely out of control of web2py). Changes to the data happen
>> asynchronously, according to business processes.
>>
>> I have three pieces:
>>
>> 1. web2py serving the data to the clients, via jsonrpc
>> 2. a small script which knows (long-polling) when changes in the
>> third-party database occur
>> 3. a library to process the information in the third-party database.
>> Calling this must be avoided at all costs, *except* when we have actual
>> changes (which is why I want to add the cache)
>>
>> The easiest implementation for me would be to be able, from the external
>> script, to invalidate the web2py cache whenever I detect changes relevant
>> to the active sessions (not the whole cache, just the part related to my
>> jsonrpc controller)
>>
>> Is this possible? Maybe by calling a web2py controller which is in charge
>> of invalidating the cache?
>>
>> What about the session? I assume the web2py cache is session-related. My
>> script should call the web2py controller using the correct session, but I
>> do not know how to handle this.
>>
>> Thanks,
>> Daniel
>>
>
--
