[Deprecated] DMZ 1.6.2 (DataMapper OverZealous Edition)

[eluser]OverZealous[/eluser]
@Jamie

The short answer is, it doesn't. There is no inherent support for extending classes (yet).

That being said, you can back multiple models with a single table. It just requires a bit of work, including overriding the save and get methods to set or clear type flags.

For example, you might have a flag called is_manager, and the Employee class clears the flag when saving, and adds a where('is_manager', FALSE) when getting, and the Manager class does the opposite.

Also, all relationships have to be mapped individually for each class if you are using this technique. You will lose the ability (in the example above) to query all Employees and include all Managers at the same time.

There is a way around some of that last piece, using the advanced relationships. In my app, I have two objects, Jobs and Service Calls. A Service Call is really a special case Job. Jobs is normal, except it clears is_servicecall for saving and getting.

Now, say I have an model called Task. In Job, it is related like this:

Code:

$has_many = array('task');

function get($limit = '', $offset = '') {
    $this->where('is_servicecall', FALSE);
    parent::get($limit, $offset);
}

// important: must allow for getting any type
function get_any($limit = '', $offset = '') {
    parent::get($limit, $offset);
}

In Service Call:

Code:

var $model = 'servicecall';
var $table = 'jobs';

var $has_many = array(
    'task' => array( 'join_self_as' => 'job' );
);
function get($limit = '', $offset = '') {
    $this->where('is_servicecall', TRUE);
    // notice: calling get_any
    parent::get_any($limit, $offset);
}

In Task:

Code:

var $has_one = array(
    'job',
    'servicecall' => array('join_other_as' => 'job')
);

Now servicecall and job are both related using the same database tables, and can be queried together using get_any.

You can also automate configuring the ServiceCall model, by having a constructor like this:

Code:

static $_sc_did_config = FALSE;
function __construct($id = NULL) {
    // only configure service call properties once (it's cached for all other copies)
    if(!self::$_sc_did_config) {
        // Fix relationships
        foreach(array('has_one', 'has_many') as $f) {
            $new = array();
            foreach($this->{$f} as $field_name) {
                $new[$field_name] = array('join_self_as' => 'job');
            }
            $this->{$f} = $new;
        }
        
        self::$_sc_did_config = TRUE;
    }

    parent::__construct($id);
}

----------

In summary: It is a lot of work to maintain, and I have yet to see a great reason to use polymorphism in a DMZ-backed app. I highly recommend avoiding it if possible. Personally, I wish I had just gone with tracking the information via the flag, and skipping the polymorphic objects, but it would be a lot of work to change the current design in my app.