Login

01-17-2009, 04:28 PM

[eluser]Jelmer[/eluser]
Update on April 16, 2010
I've moved MP_Cache to Bitbucket, following the example of EllisLab and because of the easy integration with NetBeans. Any issues can be reported there and the documentation is also there in the Wiki. And of course I invite anyone to contribute to it there.
The new URL: http://bitbucket.org/mijnpraktijk/mp_cache

Update on August 7, 2009
I've released the 2.0 (final) of MP_Cache, which comes after 2.0b5 (beta 5). There's a lot of important bugfixes in there. And I tested it with error reporting on E_ALL so this should be the first notice & warning free version. You can find it on
[[REMOVED: new URL in update above]], and I wrote a short list of bugfixes in post 17.

I chose not to include a call() function because I don't need it. Phil Sturgeon wrote a function that might be helpfull to many in post 16 of this thread.

Original content, very much outdated:

A quick warning: the new expiration functionality only works when caching arrays. I'm writing an improved second version of MP_Cache which won't have this problem and will support checking other caches to verify if it's current ("dependencies").

I want to implement caching but neither solution provided with CodeIgniter does it for me:
- DB caching uses a controller+function format which doesn't work for me as most of the site is generated by 1 function of 1 controller and the input to that function decides what models/libraries to load and to display (which view files). (most of the url requests are in the format http://mydomain.com/page_name.htm and routed & remapped) Also I can't delete on a query basis, only on a page basis which means that for changes to my navigation menu I have to delete the entire cache...
- Output caching caches too much, since the navigation is loaded dynamicly and I would have to erase my entire cache for every little edit.

So I thought of another way which probably isn't either new or very special, but I was wondering if anyone has any thoughts on it... Why it's good and why it's not.

It works by putting the part of the output you want to cache in an array and serializing that array into a custom file that would be accessable from every page/controller/model/etc...

An example of the code I'm thinking of:

Code:
$this->load->library('MP_cache');

$example = $this->mp_cache->get('example');

if ($example === false)

{

    // parts of code that generate your $example array, like for example below

    $example = $this->my_model->get_pages_from_db();

    $this->mp_cache->write($example, 'example');

}

Where the get() function either returns the cached values unserialized to the variable or returns false if there's no cache. If it returns false the following code would be executed and the values would be cached afterwards (with the write() function).

Other functions would probably include delete_all() for deleting all the cache (or all cache files within a certain directory), and delete() for deleting specific caches. The above example would need the cache to be deleted when an update to the db occurs, so in keeping with the example I'd add the following code to my update function within "my_model":

Code:
$this->mp_cache->delete('example');

Any thoughts on this? Maybe it's incredibly redundant but I haven't found any such functionality and it would solve problems like:
- Compared to DB caching: Reusable. Some parts (like your site menu's) is the same on every page and probably doesnt need to be cached for each individual page (even highlighting the current page should't be a problem with this solution).
- Compared to DB caching: You only have to delete it once after a change was made to any part of it and not all the cache for every page that uses the changed information.
- Compared to output cache: Not caching everything isn't a problem.
- Different cache for different uses of a function aren't a problem as you can add a variable in the cache "name"

The downsides are:
- It's harder to keep track of your cache: when to delete and when to reuse. But that's what the library is all about: it doesn't have a build-in mechanism for managing cache which means more freedom to use it as you please.

I've just started writing the library, and I'm going to "steal" havily from the native CI cache functions - I'll share whatever comes from this. But in the meantime I'd love to hear some other points of view.