When a function field is accessed multiple times without there being any 
database operations, it will be calculated the first time, cached, and 
subsequently recalled out of cache.  
https://github.com/tryton/trytond/blob/1af9530e187d766598afd55bb6399ab0a5e8689b/trytond/model/modelstorage.py#L1232

The only way to prevent this that I can find (without messing with internals) 
is to do a database operation (and thus increment the transaction counter), 
signaling to the numerous caches that they should clear.  
https://github.com/tryton/trytond/blob/1af9530e187d766598afd55bb6399ab0a5e8689b/trytond/cache.py#L219

Of course, explicitly changing the transaction counter would also accomplish 
the aim.  Does anyone know if this is acceptable?

I understand that I should probably not even be talking about such things.  Why 
would the function field have changed without a database operation?  I am in a 
strange case where I have a function field that is used to generate a report, 
but new legal guidance has been issued that creates two interpretations of how 
that function field might be calculated.  I have a wizard that runs a series of 
reports, and the idea is to now have two versions of the report: one for each 
method of calculating the function field (based on a context flag).  I 
understand that this is not great, and that idiomatically the better thing to 
do would be to either convert the function field into a regular python method, 
or use two different function fields.  I am just not investing the time to do 
that yet--in part because I think there is a good possibility of new legal 
guidance coming out fairly soon.

Any advice on how to not use the cache?  (Btw, the avenue of doing a trivial 
database operation to increment the counter also runs into problems because 
reports are run in readonly transactions.)

-- 
You received this message because you are subscribed to the Google Groups 
"tryton" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton/aa883ceb-482b-4d58-896b-5e2a887e6bda%40googlegroups.com.

Reply via email to