Using memcache

[swaldman]

This is the first time I've tried using memcache, so I thought I'd post here and check I'm doing it right.
This is perhaps a slightly unusual application, because it isn't for caching something that's in the db.

Scenario: There is a Twitter config variable that we need to know, which changes occasionally. There's a Twitter API call to find it out, but they ask that people don't call this more than once a day. So, my intention is along these lines:

#allow an override, and also a fallback for sites that don't use memcache.
return $LJ::MYVARIABLE if $LJ::MYVARIABLE

my $value = LJ::MemCache::get( 'mykey' );
return $value if $value;

#we clearly don't have it at present
#Do stuff to get the value from Twitter.

LJ::MemCache::set( 'mykey', $value, 24*60*60 );
return $value;

So, does the above make sense? Am I doing things correctly? Is there a convention as to what the key should be called?

Thanks :-)

Comments

[exor674]

How often does this variable change? and is this "everything breaks if the variable isn't set correctly"?

I don't think there's really a convention, just try not to avoid conflicts, so something like 'twitter:supermagic' or something would work ( but, uh, descriptive )
But generally that looks right.

[swaldman]

Thanks!

It's the number of characters that Twitter considers a URL to take up. It's fixed regardless of the length of the URL, because of the t.co redirect system. Every so often it increases - presumably when they run out of unique t.co redirects. I'm not sure how often, because I've only seen a change announced once since I've been paying attention, but it's at most "every few months".

So it's "any tweet notifications for posts that don't have really short subjects are considered too long and fail if it isn't set correctly" :-)

On the one occasion that I have seen a change announced, they've said that their API will start reporting the higher value about a week before the actual change, to avoid breaking things - so as long as they do that consistently, there's no problem with having a value a day out of date.

[mark]

A small thing: usually you want to use "defined" instead of "truthiness" on configuration items. I don't know what $LJ::MYVARIABLE contains, but if it ever contained a 0 or 'false' or similar, it would cause you to hit Twitter a lot.

[swaldman]

Good point, thank you.

It shouldn't ever have 0, but worth bearing in mind more generally.