There are various ways to update rows in a database table using the Zend_Db_Table components. You can use use Zend_Db_Table::update(), like so:

$table = My_Table();
$table->update(array('age' => 22), 'id = 1');

or retrieve the row, and update it:

$table = My_Table();
$row = $table->find(1)->current();
$row->age = 22;
$row->save();

The big difference between the two approaches is that by first retrieving the row, and then updating it, you're actually using three queries. The first one to find the row, the second one to save it, and a third, which is used internally in to Zend_Db_Table_Row_Abstract to refresh data that might have gotten changed due to TIMESTAMP columns, triggers, etc.

If you dig into Zend/Db/Table/Row/Abstract.php, you can see that the class already tracks which columns were changed, so if you only change the value of a single column like the age in the example, not all columns of that row are updated in the database — only those that were actually modified. That's what the protected $_modifiedFields property is for; it records which properties on the Row object were set and only writes those fields to the database. It doesn't, however, check whether the new value is different from the old value.

There's also another protected property, called $_cleanData, which contains the row data as it is currently stored in the database. With that in mind, it is pretty simple to add additional logic to take advantage of that fact.

For instance, we can take it to the next level and only update the record if the column data differs from its previous data. Or perhaps we have a separate audit trail log that needs to capture any column data that was modified.

<?php

require_once 'Zend/Db/Table/Row/Abstract.php';

abstract class My_Db_Table_Row_Abstract extends Zend_Db_Table_Row_Abstract
{

    /**
     * Returns the values that have *actually* been changed
     *
     * @return array
     */
    public function getDirty()
    {
        return array_diff_assoc($this->_data, $this->_cleanData);
    }

    /**
     * Whether the record has been modified
     *
     * @return bool
     */
    public function isDirty()
    {
        return (bool) count($this->getDirty());
    }

    /**
     * Saves the properties to the database.
     *
     * This performs an intelligent insert/update, and reloads the
     * properties with fresh data from the table on success.
     *
     * Saving will only occur if any column values have been modified
     *
     * @return mixed The primary key value(s), as an associative array if the
     *     key is compound, or a scalar if the key is single-column.
     */
    public function save()
    {
        if ($this->isDirty()) {
            return parent::save();
        }
    }
}

I built a feature based on this to record when a row was modified, exactly which columns were updated, when, and by whom, in order to provide a rock-solid audit trail for a web application in a corporate environment.

I have a Linux server with a system timezone of ET (US/Eastern). But I also have a web application that needs to run in a timezone of PT (US/Pacific). Of course that's not a problem at all. I just set the timezone in my web application's bootstrap:

date_default_timezone_set('America/Los_Angeles'); // Pacific timezone

Now I have another problem; the database. Sometimes I use PHP to generate dates such as date('Y-m-d H:i:s', strtotime('-2 minutes')). Other times I insert records and use new Zend_Db_Expr('NOW()');. But because MySQL isn't aware that I'd like to use pacific time, dates end up being inconsistent and are off by three hour.

It's a fairly easy fix, though, with a bit of logic added to a custom MySQL database adapter:

<?php

/**
 * @see Zend_Db_Adapter_Pdo_Mysql
 */
require_once 'Zend/Db/Adapter/Pdo/Mysql.php';

/**
 * MySQL PDO adapter extended to set the timezone
 */
class My_Db_Adapter_Pdo_Mysql extends Zend_Db_Adapter_Pdo_Mysql
{
    /**
     * @var bool
     */
    protected $_initialized = false;

    /**
     * Connects to the database.
     *
     */
    protected function _connect()
    {
        parent::_connect();

        if (!$this->_initialized) {
            $this->_initialized = true;

            if ($this->_config['timezone']) {

                // Requires PHP 5.2+
                $dtz = new DateTimeZone($this->_config['timezone']);
                $offset = $dtz->getOffset(new DateTime('NOW')) / 60 / 60;

                $this->query(sprintf("SET time_zone = '%d:00'", $offset));
            }
        }
    }
}

To kick this all off my bootstrap contains:

$config = array();
$config['host'] = 'localhost';
$config['username'] = 'username';
$config['password'] = 'password';
$config['dbname'] = 'mydatabase';
$config['timezone'] = 'America/Los_Angeles';
$config['adapterNamespace'] = 'My_Db_Adapter';

$db = Zend_Db::factory('PDO_MYSQL', $config);
Zend_Db_Table::setDefaultAdapter($db);

date_default_timezone_set('America/Los_Angeles');

And now I am free to continue my habit of inconsistency when specifying dates.

There are all kinds of ways to expose APIs as web services. SOAP, XML-RPC, REST, JSON-RPC. Out of all of these, SOAP is arguably the most complex, but also one of the oldest ways to expose an API (I remember preliminary SOAP and WSDL support in Delphi 6, circa 2001).

Exposing an API as a web service in Zend Framework is fairly straight forward, in fact it is (or should be) as easy as one, two, three:

  1. Pick your favorite style (Zend_Soap_Server, Zend_XmlRpc_Server, Zend_Rest_Server, Zend_Json_Server).
  2. Define a properly documented class with the methods and business logic that you want to expose.
  3. Let your Zend_*_Server::handle(); everything else.

That's pretty much it. Of course each Zend_*_Server has its own settings and options that you can (and sometimes must) configure. XML-RPC is also the only server that supports namespaces.

If you decide on using SOAP, there are a few things to watch out for.

  1. The WSDL generator doesn't let you set the TargetNamespace attribute explicitly. This becomes an issue when you're working with different environments (development, testing, staging, production, etc.) since the URL of the service determines the namespace. And that makes automatic code generation based on the WSDL problematic. I've contributed a patch to address this, as part of ZF-4117.
  2. Zend_Soap_Client contains a bug that prevents it from properly proxying method calls. Instead, it'll end up recursing infinitely, or at least 100 times before PHP detects the issue and kills it. The quick fix of removing a single underscore froma method call is outlined in ZF-4152.
  3. Zend_Soap_Server doesn't properly turn Exceptions into SoapFaults (due to lack of typecasting) as described in ZF-3958. You can still throw SoapFaults explicitly, but that's just bad form since your class shouldn't be SOAP specific. After all, you may decide to also expose it as XML-RPC or what have you, and then the SoapFault, while it might still work properly, is semantically incorrect.
  4. While Zend_Soap_Server and Zend_Soap_Client are mostly wrappers for the native PHP SoapClient and SoapServer classes, PHP itself lacks WSDL generation which Zend_Soap_AutoDiscovery provides in conjunction with Zend_Soap_Wsdl. Unfortunately the notion of "array of datatype" is not supported, since arrays in PHP are simply declared as "array" and can contain anything. Zend Studio's WSDL generator supports the syntax of "string[]" to specify an array of strings, and this works with complex types as well. "User[]" is an array of User objects. The issue is outlined in ZF-3900, to which I didn't provide one, but two patches, neither of which actually do what I thought they'd do (go me!). However, I have put together an embarrassing hack (Zend_Soap_Wsdl arrayOfType patch) that finally does work — at least for me. So far I haven't worked up the courage to submit it to JIRA. Not one of my finest moments.

I doubt most of these issues will hang around for long, but if you're developing something SOAPy with ZF1.6, you'll like encounter at least one of them.

After I had upgraded from Firebug 1.2.0b7 to 1.2.0b15, my web apps were no longer throwing any kind of logs into the Firebug console. I'm using the Zend_Log_Writer_Firebug class for that.

Luckily, just earlier today I noticed a new release of Firebug 1.2.0. And with that, FirePHP 0.1.1.2. But now there was a new problem:

["There was a problem writing your data from the Wildfire Plugin http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1", Array(4)]

That, of course, wasn't helping any. So I checked the release notes and noticed issue #14, which is a copy of ZF-4020. Since I'm stuck with ZF1.6 RC2 and would rather not pull from the trunk, I figured I'd test to see if I could fix it myself. Followed the code through to Zend/Wildfire/Protocol/JsonStream.php line 203 and replaced $part); with '|' . $part . '|'); Works great!

And I just noticed that ZF1.6RC3 was released. And it includes the fix, of course. Quite a chain reaction. A bug in Firebug's tabWatcher.js gets fixed, causing a refresh issue with FirePHP, which fixes the issue and also adds a workaround for a problem with whitespace disappearing, which requires a new ZF release candidate. All is well at last.

Evidently 2008 is the year of the aggregators. They're everywhere. Socialthing, ping.fm, and what have you. But here's one with an immedialy obvious business model. Introducing Spokeo. An aggregator that asks you to provide your AOL, Gmail, Hotmail or Yahoo email credentials (which, in my opinion isn't the safest way to share contacts and I wouldn't divulge that kind of information) to load all your contacts from your address book and then tries to connect all the dots.

Spokeo advertises that individuals who give up their email account credentials can find out "secrets" about their friends. The same information that's available free to individuals (well, subsidized by allowing Spokeo to harvest your contact list) is also sold to anyone who'll pay for it. Specifically, they're targeting HR departments.

Their business model is providing in a way, a social media-based public information "background check" to companies. And that's probably a very appealing thing to Old Economy Mega Bank Corp. which will use this service to see what potential job candidates have been up to on 43 Things, Amazon, Bebo, Blogger, Buzznet, dailymotion, deviantART, Digg, Facebook, Flickr, Flixter, Fotolog, Friendster, Hi5, iLike, imeem, Last.fm, LinkedIn, LiveJournal, Multiply, MySpace, Netlog, Pandora, PhotoBucket, Picasa, PictureTrail, Slide, StumbleUpon, Twitter, Upcoming, Veoh, Vox, Web Results, WebShots, Windows Live Spaces, Wretch, Xanga, Yelp, and YouTube.

So, if work hard and play hard, make sure what happens in Vegas stays in Vegas.