On Dec 1, 9:44 am, pbx <
paul.bis...@gmail.com> wrote:
> * The "simple" backend seems obsolete. The newer "locmem" is
> functionally equivalent for the user, but is suitable for deployment
> as well as development. Should "simple" be removed? This might allow
> refactoring of the backend code to simplify its inheritance structure.
Yeah, that sounds like a good idea. I'd like to see a patch that
aliased "simple" to "locmem" and raised a DeprecationWarning. We'll
then remove simple in 1.0.
> * "cull_percentage" is called "cull_frequency" inside the code;
> neither is a great name, but the second is better. Worth changing?
Ugh, I hate to break existing code for a change from a crappy name to
a slightly better one. I think it's not worth it unless someone can
come up with a *really* good, intuitive name.
> * A documentation question: Does "manage.py createcachetable" create
> an indexed table? if so, we don't need to repeat their admonition
> about making sure the table's indexed.
I *think* it does, but you should double-check. It should, so a patch
to make it do so would be great.
> * Should the "file" backend's _file_for_key method be rewritten to use
> hashes instead of cleaned-up strings? It fails to correctly handle an
> empty string, which is a valid string and dictionary key otherwise.
Yes - hashes are better. Even better would be to do a bit of
subdirectory creation based on hashes to prevent problems on
filesystems that don't like millions of files in the same directory.
Something like "6f/1e/d002ab5595859014ebf0951522d9.pickle" or
whatever.
Thanks!
Jacob