> 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.
> 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. -- Gustavo Niemeyer http://niemeyer.net -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
