in reply to Saving MySQL Queries in an XML format

Why XML for data serialization? Do you need human readable cache storage? If not you could use Storable instead of XML::Simple.

Morever you could use Cache::Cache to handle caching. This module provides quite high level API for data cache (and AFAIK it uses Storable to serialize/deserialize data).

I've rewrote you example using Cache::Cache:

# init cache object at the begining of the program my $CACHE = new Cache::FileCache( ); ..... ..... #### Cut, subroutine from module foreach my $tid (@completed){ $results{$tid} = $CACHE->get($tid); unless(defined $results{$tid}) { $results{$tid} = $self->Complex_Crap($tid); # data will expire in cache in 10 minutes $CACHE->set($tid => $results{$tid}, "10 minutes"); } } $self->Results(\%results); return($self); }

Update: Added example of Cache::Cache usage.

--
Ilya Martynov (http://martynov.org/)

Replies are listed 'Best First'.
•Re: Re: Saving MySQL Queries in an XML format
by merlyn (Sage) on Jul 05, 2002 at 15:34 UTC
    Beware. Cache::Cache is meant as a cache, not as a storage mechanism. It could reply "not found" to every single request to recover a previous value, and still be fully within spec (although a poor implementation).

    The point of a cache is to possibly avoid re-computing a computable item, not to hold a non-computable item.

    To store a non-computable item, use a proper database.

    -- Randal L. Schwartz, Perl hacker

      Well, it's not just a simple query against the database. On some a complex queries (the ones I'm storing in XML), there are 10 to 15 separate database hits and then some calculations on the values I'm getting back out of it. Then I'm sticking all of the values into a reference (for moving the data from module back to caller) then it is a big help to store that reference using XML::Simple. The whole interface of XML::Simple is built around storing and reading references, so I didn't need to do any 'extra' work to start using it.

      The ability to export my ready-made XML objects to other systems is just icing on the cake. In future improvements, I can see the possibility of a customer not wanting to deal with data over my web portal, but being able to import my data directly into their back-end.

      I guess what I'm trying to figure out is, if this was a crazy way to implement this solution, and it looks like it's not TOO crazy :)
      -oakbox