Re^3: Selecting one of two implementations

I don't understand. Are you making a cache, or a database?

You keep using the word cache. What are you caching? A cache means you are saving one calculated result in an attempt to avoid recaculating it again. A cache also means it can simply disappear, and it shouldn't affect any part of your design except to slow it down a bit. (In fact, your program should still work even if the cache was completely forgetful.)

So, are you building a cache, or a database?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Comment on Re^3: Selecting one of two implementations

Replies are listed 'Best First'.
Re^4: Selecting one of two implementations by Tanktalus (Canon) on Apr 25, 2005 at 15:43 UTC
Forgive my improper terminology - I didn't take computer science, so I may be using terms incorrectly. I would definitely like to extend the module into a cache (which would include a callback to generate missing information), but I suppose that we're looking more at a database. My confused terminology actually comes from my investigation of Cache::Cache. The documentation uses the example: `use Cache::FileCache; my $cache = new Cache::FileCache( ); my $customer = $cache->get( $name ); if ( not defined $customer ) { $customer = get_customer_from_db( $name ); $cache->set( $name, $customer, "10 minutes" ); } return $customer;` [download] So, if our calling code is implemented similarly, then the database becomes a cache. (Generating 200MB tar.gz files off the network isn't free, but using already-built tarballs from the local drive is about as free as it's going to get.) The way our code works now is that we start with a preparation phase, where the cache/database is populated with things that are going to be needed 1-15 times. Then we enter the execution phase where we pull items from the cache/database as needed to build what we need to build. Note that we've also given thought to actually using an RDBMS rather than the filesystem to allow us different flexibilities - e.g., having multiple machines pull from the common cache via DBI. Or using FTP or HTTP as protocols to do similarly. The RDBMS idea is more of a coolness thing - FTP or HTTP are probably better (i.e., more practical) protocols for this.	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: Selecting one of two implementations
by Tanktalus (Canon) on Apr 25, 2005 at 15:43 UTC

Forgive my improper terminology - I didn't take computer science, so I may be using terms incorrectly. I would definitely like to extend the module into a cache (which would include a callback to generate missing information), but I suppose that we're looking more at a database. My confused terminology actually comes from my investigation of Cache::Cache. The documentation uses the example:

  use Cache::FileCache;

  my $cache = new Cache::FileCache( );

  my $customer = $cache->get( $name );

  if ( not defined $customer )
  {
    $customer = get_customer_from_db( $name );
    $cache->set( $name, $customer, "10 minutes" );
  }

  return $customer;
[download]

The way our code works now is that we start with a preparation phase, where the cache/database is populated with things that are going to be needed 1-15 times. Then we enter the execution phase where we pull items from the cache/database as needed to build what we need to build.

Note that we've also given thought to actually using an RDBMS rather than the filesystem to allow us different flexibilities - e.g., having multiple machines pull from the common cache via DBI. Or using FTP or HTTP as protocols to do similarly. The RDBMS idea is more of a coolness thing - FTP or HTTP are probably better (i.e., more practical) protocols for this.

[reply]
[d/l]