namespace bids

[Cahill, Earl]

> We have worked around this in our application.  Any cache we create
that
> is not quantifiable (like unnamed sql query cache) is logged to a
mysql
> table using insert delayed.  We store various information about it
that
> could be considered a namespace.  We then query this table and delete
> any keys found in there.  We then delete any rows from the table older
> than when we queried that match our criteria.  It leaves a small
window
> of error, but so far, its not a problem.

Seems like if you lock for adds and deletes, and somehow make sure all
the insert delays are finished (thinking there's a way to do this, but I
am not sure), then you should be about perfect.

> For other data, we simply delete all keys we can create such as
article
> cache.  We just loop through all known article ids.  Its quite fast.
> Have you tried looping through all your "fred" data and removing it?
> You might be surprised.

Problem is that right now we don't keep track of all the sets in fred.
I have pondered keeping track of keys in memcached, but yeah, maybe
mysql would be a better option.

Based on brad's silence, and the fact that he posted on a different
topic, I get the idea that namespaces are never likely going to be in
memcached.  Kind of hoped that if we offered to actually pay for it, it
might make it in, but not looking like it.

So, yeah, maybe I could write something outside of memcached, in perl,
that mimics namespaces.  Like Cache::Memcached::Namespace.  Which might
have Cache::Memcached::Namespace::mysql and
Cache::Memcached::Namespace::Memcached to keep track of keys in the
namespace.  I could even use my Cache::Memcached::Lock to lock.

It would likely end up much like your solution.  We have almost done it
here, but in a less structured way, and I kind of like the idea of the
key names being outside of memcached.

Of course the big thing is that gets would hopefully be transparent.
And I think that gets are what it's all about.

Thoughts?

Earl