FOSS Fridays: MacGyvered Key/Value in Symfony
Posted on:Friday, August 7th, 2009 by Ashish DattaOn a project we’re currently working on, we arrived at a situation where our client had a loose and very fluid idea of the information he wanted to store about certain objects in his application. We didn’t specifically know the number of fields or the format of the data. Continually modifying the schema would of been painful so I wanted to try something different.
Since the data is more or less non-relational (it only relates to the object that owns it), what I really wanted was an ad-hoc key/value store. But I didn’t want to break Propel’s ORM abstractions. I still wanted to be able to do:
$company->getMission();
With the new system.
Turns out you basically can. Here’s how it works:
- Add a “dynamic_field” table to your schema. (definition is below)
- Override the __call(), hydrate(), and save() functions in Propel model file that you want to MacGyver.
- Pray.
Definition of the dynamic_field table:
So the idea is we want to basically build a Propel Behaviour to capture any undefined get/set calls and “get” the data out of the dynamic_field table or “set” the data by storing the value into the table. Since the table stores the model class and model id, the “keys” only have to be unique by model (just like Propel normally works).
Here is the code you need to add to the model file:
public function __call($method, $arguments){
// snag the dynamic setters
if(strpos($method, "set") !== false
&& $method[3] === strtoupper($method[3])){
$name = strtolower( substr($method, 3) );
$this->dynamicFields[ $name ] = array_pop( $arguments );
return true;
}
// snag the dynamic getters
if(strpos($method, "get") !== false
&& $method[3] === strtoupper($method[3])){
$name = strtolower( substr($method, 3) );
if( array_key_exists($name, $this->hydratedFields) ){
return $this->hydratedFields[$name];
}
if( array_key_exists($name, $this->dynamicFields) ){
return $this->dynamicFields[ $name ];
}
return null;
}
return parent::__call($method, $arguments);
}
public function hydrate($row, $startcol = 0, $rehydrate = false)
{
parent::hydrate($row, $startcol, $rehydrate);
// pull in our dynamic fields while we're at it
$c = new Criteria();
$c->add( DynamicFieldPeer::MODEL, get_class($this) );
$c->add( DynamicFieldPeer::MODEL_ID, $this->getId() );
$dynamic = DynamicFieldPeer::doSelect( $c );
foreach($dynamic as $d){
$this->hydratedFields[ $d->getFieldName() ] = unserialize( $d->getFieldValue() );
}
return true;
}
public function save(PropelPDO $con = null){
// save the dyanmic ones
if( count($this->dynamicFields) ){
// grab the old ones and update stuff
$keys = array_keys($this->dynamicFields);
$c = new Criteria();
$c->add( DynamicFieldPeer::MODEL, get_class($this) );
$c->add( DynamicFieldPeer::MODEL_ID, $this->getId() );
$c->add( DynamicFieldPeer::FIELD_NAME, $keys, Criteria::IN );
$savedFields = DynamicFieldPeer::doSelect( $c );
foreach($savedFields as $sf){
$sf->setFieldValue( serialize( $this->dynamicFields[$sf->getFieldName()] ) );
$sf->save();
unset( $this->dynamicFields[$sf->getFieldName()] );
}
foreach( $this->dynamicFields as $key => $val ){
$df = new DynamicField();
$df->setModel( get_class($this) );
$df->setModelId( $this->getId() );
$df->setFieldName( $key );
$df->setFieldValue( serialize( $val ) );
$df->save();
}
}
return parent::save($con);
}
The code captures any undefined get/set calls and then deals with them appropriately. It won’t serialize the fields until the save() call (just like regular Propel objects). I also overloaded the hydrate() function so that the object will fetch all of its dynamic fields in one shot, as opposed one query per get.
Using the modified objects is exactly like regular Propel objects, the changes are entirely transparent except that you can get/set anything you want.
For example:
$company = CompanyPeer::retrieveByPK( 5 ); $company->setVision( "this is my vision" ); echo $company->getVision();
Will work even though there is no “vision” column on the company table. Magic.
There is one big problem with this trick though. Because of the Propel class hierarchy, there isn’t any way to introduce this code in one file and have other objects inherit the changes. You have to manually copy it to any model file that you want to enable it for.