size management and auto-removal for the memory backend

Issue #22 wontfix
created an issue

was this left out for a philosophical/practical reason or just a lack of necessity ?

Comments (5)

  1. Michael Bayer repo owner

    well that's not exactly trivial to implement (what algorithm for size management?) , the idea is if you need a real cache you'd be using memcached.

    what's "auto removal" ?

  2. jvanasco reporter

    removal when the expiry-time passes. the docstring just said it did neither.

    There is no size management, and values are placed into the dictionary will remain until explicitly removed. Note that Dogpile's expiration of items is based on timestamps and does not remove them from the cache.

    practical reasons is a good answer. i was just wondering while digging through the backends.

  3. Michael Bayer repo owner

    oh. yeah that's all because that kind of stuff isn't really trivial to implement correctly. the memory backend is more like a sample backend unless you really have some fixed-size data to cache.

    I'd rather find someone whose implemented some kind of in-memory storage engine and make a backend on top of that, rather than doing anything with the included memory backend.

  4. jvanasco reporter

    I was thinking the same thing, and hoping you found that person/already did it ;)

    I'm trying to optimize some database selects in a twisted daemon. This thing has so many parts, I'd rather avoid memcached... but I have no problem using it.

  5. Log in to comment