> On Nov 6, 2:42 am, mdipierro <[email protected]> wrote: > > > I found the problem. > > > There is, there always was, a bug in cache.ram. It was caching the > > original object, not a copy, so if the object gets modified the one in > > cache changes too. > > > This bug only showed up now. > > > I fixed in trunk and I will post a web2py 1.71.3 asap. > > > For now you can still use the latest web2py but edit gluon/cache.py > > add > > include copy > > and replace > > self.storage[key] = (time.time(), value) > > with > > self.storage[key] = (time.time(), copy.deepcopy(value)) > > > Massimo
On Nov6, 2:46am, vince <[email protected]> wrote: > thanks for your quick fix! > > vince > I met the same problem and am happy to see Vince and Massimo combine for a quick debug and fix. Thanks! But, do we really need a deepcopy? Or shall we just cache the original copy, so that the cached version is always up-to-date? Besides, what if the instance to be cached is not deepcopy-able? It happens in some of my apps, so the latest fix still don't work for me. :-/ Perhaps we can add one more parameter for CacheInRam.__call__(..., deepcopy=True) for flexibility? Hope to hear more feedback on this. Thanks. Regards, Iceberg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
