I have a group of model peer classes that should all have the same functions. Rather than copying and pasting to each every time I add a new one to the group, I would rather add the functions to a class the model peer classes extend. Unfortunately, as the model peer classes extend from Base classes such as BaseModelPeer, it’s not possible.
Propel 1.5 has added a basePeer attribute, which can allow you to set BaseModelPeer to extend from a given class. However, by default, a BaseModelPeer class does not extend from anything. Instead, it just makes all its calls to the BasePeer class, which has different signatures for its functions. By changing the basePeer attribute, the BaseModelPeer extends from your new class, let’s call it NewBasePeer, and changes the calls to BasePeer to NewBasePeer. As the signatures differ, though, this just causes it to fall apart!
I am actually trying to follow on from Symfony’s Zend Lucene tutorial, moving some of the functions which make items indexable to this NewBasePeer class. One of these functions is doDeleteAll. BaseModelPeer’s signature of this function looks like this:
public static function doDeleteAll($con = null)
But inside this function it makes a call like this:
$affectedRows += BasePeer::doDeleteAll(ModelPeer::TABLE_NAME, $con, ModelPeer::DATABASE_NAME);
As BaseModelPeer doesn’t extend BasePeer, it’s fine. But by changing the basePeer attribute in the schema, the function call changes to:
$affectedRows += NewBasePeer::doDeleteAll(ModelPeer::TABLE_NAME, $con, ModelPeer::DATABASE_NAME);
BaseModelPeer now extends NewBasePeer, meaning for it to override the call to doDeleteAll(), they need identical signatures. Clearly the BaseModelPeer class is now contradicting itself!
Is this a bug with Propel? If not, how is one meant to use the basePeer attribute?
The correct way is to define a Propel Behavior