On 01.09.2007, at 01:57, Gustavo Niemeyer wrote: > >> hm what about: > (...) >> and the store._cache stays as it is > > Sorry, I missed your previous point. Of course we would be able to > explicitly deallocate objects by asking the store to do so. But I'd > really like to prevent that kind of manual fiddling. Instead, I > suggest a smarter (maybe pluggable) caching policy.
+1 > >> yes, the above set could be a set/list with a maximum objects that >> automatically pops out old ones > > Right! > >> i see, probably it would be best to implement the hard refs in the >> zope >> datamanager and make it a parameter e.g: keepRefs > > I think that wouldn't be the right place to put it. The only thing > zstorm cares about is store management so far, and caching is > something > only known to the Store. > this is reasonable ... i just thought about that we might have zope specific caching requirements, that might be common to zope applications, such as ReferenceSet caching etc. But as you said, it is the job of a pluggable caching mechanism. When do you think will such someone find time to implement caching. Or shall we (lovely) start to do this? > -- > Gustavo Niemeyer > http://niemeyer.net -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
