CODEWITHSUNDEEP
phpoopapicachinginterface
Trott
Trott

Reputation: 70105

Caching API/Interface To Use As A Model

I'm writing a caching API in PHP. It does everything I need it to do, but I'm contributing it back to a project where other people may use it for other things. In the code review, I was asked to make sure that it had all the standard methods one expects in a caching API.

I've looked at PHP's Memcache API, and Zend's caching API, and a few others, and there doesn't really seem to be a standard. They certainly don't agree on names for methods (read() vs. get() vs. etc.).

So, should I just make sure I can do CRUD operations and call it a day? Throw in a flush() for good measure?

Or is there a sort of standard generic model I can use for a caching API?

Or should I go to the mat and argue stringently that we shouldn't implement anything until it's actually needed?

Upvotes: 4

Views: 386

Answers (1)

kijin
kijin

Reputation: 8910

What kind of backend are you using for the cache? Memcached? Redis? APC? Flat files?

  • If you're only going to support one backend (like Memcached), you should probably follow that partular backend's methods as closely as possible.

  • If you're going to support multiple backends, your core methods should probably feature the common denominator among them all.

As far as the "standard" is concerned, most people would be looking for SET with optional expiration, GET, EXISTS, DELETE, FLUSH, and (if possible) INCREMENT/DECREMENT, with the same method names. Those methods are available in virtually every caching API. But anything more will depend on what the backend supports.

For example, Memcached supports CAS, APPEND, and atomic ADD/REPLACE, but many other backends don't. Even if you hack similar methods onto a backend that doesn't support them, the resulting operations will not be atomic, which can lead to subtle bugs down the road. The problem is not that they're not needed yet. The problem is that they will be buggy if slapped onto a backend that doesn't support them.

Zend_Cache is very complicated because it supports pretty much every conceivable backend, and includes a lot of tricks to make them behave similarly. For example, it makes heavy use of locking to prevent potential race conditions with flat file operations. But you probably shouldn't be reinventing the wheel if that's what you're after.

Upvotes: 1

Related Questions