tag proposal

Dustin Sallings dustin at spy.net
Mon Oct 8 22:38:53 UTC 2007

On Oct 7, 2007, at 15:03 , Brian Aker wrote:

>>> 	Tags aren't intended to be an index, just a mass invalidation  
>>> mechanism.  It's *possible* to use them as an index, but not in  
>>> any cheap way.
> I can imagine that they will get used as such though. Give someone  
> a wrench, and if they need to do surgery, and lack the proper tool,  
> somehow they will use the wrench  :)

	I agree.  That's why there were no plans to provide the set of items  
tagged with a given tag.  :)

>>> 2) Allow the "set" of an object with its tag name. This will  
>>> solve the problem of creating an object and then tagging the object.
>> 	If you can prove that setandtag is *considerably* cheaper than set 
>> +tag, then it could possibly be added as an extension.
> It would be hard to say until I saw the implementation. The cost of  
> parsing out the extra  bit of information, vs parsing out an  
> entirely new command. The nice thing about one command is you can  
> get a more atomic response. AKA my client dies between set and tag.

	In the case of the binary protocol, it's effectively pre-parsed.  In  
general, I don't think the cost is worth considering.

	Atomicity may be, but it can make the protocol dirty.  This is  
getting back to the MVCC part of the discussion.  Does it make more  
sense to combine two discrete concepts into one command to effect  
atomicity or have a generic transactional wrapper mechanism.

>>> 3) Clear an object from a tag.
>> 	You mean untagging an object?  It's not clear to me how that  
>> would ever be used.  I imagine people will be setting and tagging  
>> around the same time, and would never want to go back and say,  
>> ``no, that really *isn't* dependent on this information.''
>> 	How would you imagine this being used?
> Having an object belong to multiple tags, but allowing me to remove  
> it from a particular tag set. For instance on slashdot you could  
> request all stories under a certain tag, but if users decided that  
> the tag was no longer accurate it could be removed.

	I'm not sure that really works.  The only reason you'd tag it is if  
you wanted to delete it.  Tags would typically be based on the  
contents of a cache value.  Revoking a tag would suggest that you  
made a mistake.  It is to say, ``I actually *don't* want to delete  
this when this tag invalidates because it really doesn't contain the  
thing I said it does.''

> And yes, if you have multiple tags on an object, it is possible to  
> do secondary indexes.

	It's getting more expensive, though, and just to solve a problem it  
wasn't intended to solve.

Dustin Sallings

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20071008/82f418c7/attachment.html

More information about the memcached mailing list