TW Blog :: Entries for PHP

Viva PEAR::Cache_Lite

Also relates to PEAR

With the latest release of the PEAR::Cache the Cache_DB extension has been removed. I first came across Cache_DB in the PHP Cookbook last year and ran several tests to integrate it as a principle caching mechanism in the Content Management System. However, the class offered no noticeable benefit in performance, and when several database calls were being executed for a single page, it did not make sense to use a cache per query. So as an alternative I decided to test drive the PEAR::Cache_Lite package instead. As its nomenclature suggests, this is an excellent lightweight package and offers the perfect solution for filling the caching void in content retrieval. One of the package extensions is <a href="http://pear.php.net/manual/en/package.default.cache-lite.cache-lite-function.cache-lite-function.php" title="Current End User Documentation on Cache_Lite_Function">Cache_Lite_Function</a>, a caching class for functions. This allows for several database calls and the template system to be wrapped in a single method for caching:

class SS_Content {

  // [..snip..]
  
  function fetch($action, $caching = NULL)
  {
    $this->action = $action;
    
    if ($caching === NULL) {
      if (isset($this->_caching)) {
        $caching = $this->_caching;  
      }
    }
    
    if ($caching === SS_CACHING_ON) {
      return $this->retrieveCache();
    }
    else {
      return $this->retrieve();  
    }   
  }
  
  function retrieveCache() {    
    require_once "Cache/Lite/Function.php";

    $options = array(
      'cacheDir'     => CACHE_DIR,
      'lifeTime'     => CACHE_EXP
    );
    $objCache = new Cache_Lite_Function($options);
    return $objCache->call(
      $GLOBALS['_SS_Content_Obj'] . '->retrieve');           
  }
  
  function retrieve()  { 
  
    // this is where the content is built
    // eg database retrieval and content 
    // creation with a template system
  
  }
  
  // [..snip..]
}

This is only a raw example, since within its actual context, SS_Content is actually an abstract class serving specific modular extensions. But it shows how simple Cache_Lite is to use - create the object and invocate the <a href="http://pear.php.net/manual/en/package.default.cache-lite.cache-lite-function.call.php" title="End user documentation on the call method of Cache_Lite_Function">Cache_Lite_Function::call()</a> method. There is one area of caution when using Cache_Lite in an OOP environment like this. The method will look for an object in the global name space equating to the name preceding the accessor operator in the parameter string of the method. How this is achieved is dependant on the application and naming conventions. One solution is to register the variable name of the object in a global variable during instantiation of the class (as demonstrated above).

Melon Fire provides a terse but detailed introduction to Cache_Lite, Cache_Lite_Function and its counterpart Cache_Lite_Output.

Posted on Jun 20, 2004 at 03:40:35. [Comments for Viva PEAR::Cache_Lite- 0]

Enforce Referential Integrity With DataObjects

Also relates to PEAR and Databases

The PEAR::DB_DataObject package is rapidly becoming an integral part of my development arsenal. Building small scale content management becomes surprisingly simple, producing code in the CMS API layer that is concise and clear. Here is a little walk through comparing this package with its uncle - PEAR::DB - for batch deletions.

Take a simple shopping cart that includes customer and order entities as part of a wider database. These are inevitably linked in a one-to-many relationship on the customer_id field. As part of a spring clean, we want to remove all customer records that do not have an associated order record (i.e. all customers that have not placed any orders), while enforcing referential integrity. A typical DML method to achieve this is a LEFT JOIN as follows:

SELECT
  customers.customer_id
FROM
  customers LEFT JOIN orders
ON
  customers.customer_id = orders.customer_id
WHERE
  orders.customer_id = NULL  

The following snippet uses PEAR:DB to perform the batch deletion, based on the result of the above SQL:

$db =& DB::connect(ss_dsn());
$query = "SELECT customers.customer_id "
       . "FROM customers LEFT JOIN orders "
       . "ON customers.customer_id = orders.customer_id "
       . "WHERE orders.customer_id IS NULL";
$result = $db->getAll($query);
$prh = $db->prepare('DELETE FROM customers WHERE customer_id = !');
$sth = $db->executeMultiple($prh, $result);

Here, the getAll() method is used to return the set of results as an array of arrays, so they can be plugged directly into the executeMultiple() method with a prepared statement. The same result could be achieved by walking through the result set deleting each record in turn. For example:

$result = $db->query($query);
while ($result->fetchInto($record, DB_FETCHMODE_OBJECT)) {
  $db->execute($prh, array($record->customer_id));
}

Ok, now let us walk through the process using DB_DataObject. The approach is quite different. One of DataObject's main features is to make the DML virtually transparent, and rather than working with field values stored in arrays, we are working directly with the entities mapped onto objects.

1. Create an instance of the customer object
2. All customers records need to be examined, so set a select condition to retrieve all records
3. Create a result set by executing the find() method
4. Iterate over each customer and test for the existence of a link by attempting to create a linked orders object
5. If the test fails, remove the customer

Here is the snippet:

$customer =& DB_DataObject::factory('customers');
$customer->whereAdd('user_id > 0');
$customer->find();
while ($customer->fetch()) {
  if(!$customer->getLink('customer_id', 'orders', 'customer_id')) {
    $customer->delete();
  }
}

Removing the SQL from this layer makes the code considerably less error prone, especially if the relationship is threefold or greater. This approach can be readily adapted to the case of a single deletion. To ensure referential integrity will not be violated when removing a record, SQL statements must be executed against all entity classes holding a relationship with the current record. With DataObjects the database queries are executed internally, and all the current layer needs to do is test for link objects. Multiple relationships can actually be stored in a links.ini configuration file, and the integrity test achieved by simply calling the getLinks() method.

The release of PHP 5 Release Candidate 1 sees a dramatic step forward for PHP into Object Orientated design and development. PEAR::DB_DataObjects complements this nicely.

Posted on Mar 27, 2004 at 04:51:18. [Comments for Enforce Referential Integrity With DataObjects- 0]