in reply to Re: Caching data with mod_perl
in thread Caching data with mod_perl

The purpose is to keep the "do_it()" and other subroutines (which take a long time) from running every time.
I don't really know what you mean by my "approach", this is just what I came up with to cache data with mod_perl. Mostly what I'm looking for is some guidance on the pros and cons of doing it the way I've shown: such as using "our" in the Cache module.

As I said before, I'm only interested in learning about caching information within a mod_perl proccess. I'm not interested in using a module to do it because then I don't learn anything. :-)

-caedes

Replies are listed 'Best First'.
Re: Re: Re: Caching data with mod_perl
by chromatic (Archbishop) on Jul 14, 2002 at 07:38 UTC

    One con of is that each child process will have to maintain its own cache -- written memory will be copied, not shared, between processes.

    I'm not interested in using a module to do it because then I don't learn anything.

    You are allowed to read the source code of the Memoize module, as well as MJD's article on the subject. Seriously, you're more likely to learn a hundred wrong ways to do something than you are to stumble across a good approach by accident.

Modules vs DIY
by Aristotle (Chancellor) on Jul 15, 2002 at 15:39 UTC

    I agree with chromatic++ on this one. Avoiding modules in order to "learn" something is an idea that took me a long time to overcome, and I still wrestle with it quite frequently. Many problems seem deceptively simple, but you are likely to reinvent nothing other than the same mediocre (to avoid a worse term) solution with the same inherent problems that many other novices before you came up with. (Manually parsing CGI parameters or recursing through directories f.ex are commonly undertaken problems that you actually need a very solid understanding of the subject at hand for before you can take a stab at them yourself.)

    I don't mean to sound berating. I started out as a total newbie myself, as has everyone else. I've written bad code in the past that I now sneer at, and I still continue to learn how to write things in better ways every day. By all means do play around; I don't wish to discourage you from experimenting, and learning is best done by making your own mistakes and taking lessons home from them. Growth comes through error. You are definitely encouraged, as chromatic noted, to study the modules' source code and learn from it.

    However, when writing production code, please stick to modules. It means you will have less code to write yourself and consequently to maintain. And when you look back at the source in 2 years, or your successor does then, there will be less things to figure out. Also, the modules will correctly handle a lot of details that you likely didn't even know about at the time. It is no shame or stigma that your experience is as of yet limited but please acknowledge and remember it when writing code that others need to rely upon. Priorities differ then. It was a hard lesson that took me a lot of time to learn.

    Makeshifts last the longest.