I am doing all sorts of stuff with Propel that is probably a bit edge case – specifically I have found that a classname associated with a tablename is cached somewhere, and due to my rebuilding a model with different classnames but same table names (for unit testing purposes) Propel is getting in a right pickle. (You won’t need Propel experience for this question; just an understanding of PHP, probably magic calls in particular).
To debug this issue, I have found that Propel populates a “tablemap” class for a table when a column value is being set. My intention is to work out where in the code this population takes place, so I can clear the cached tablemap(s) in Propel.
Specifically, the class TestOrganiser has a generated parent BaseTestOrganiser, and this has a column setter method thus:
// The ** lines are mine, the rest are auto-generated by propel.
// The output when setting a value and saving is "no yes " which
// shows that the '$this->modifiedColumns[]' line triggers the
// tablemap population
public function setName($v)
{
if ($v !== null) {
$v = (string) $v;
}
if ($this->name !== $v) {
$this->name = $v;
$map = Propel::getDatabaseMap('test'); // **
echo $map->getTables() ? 'yes ' : 'no '; // **
$this->modifiedColumns[] = TestOrganiserPeer::NAME;
echo $map->getTables() ? 'yes ' : 'no '; // **
}
return $this;
} // setName()
As per the comments, the value of $map->getTables() moves from empty to non-empty as a result of the $this->modifiedColumns[] = TestOrganiserPeer::NAME line. However, there is no __set() method in this class or its child or parents, so I am quite mystified what code could be triggered here.
Any ideas?
D’oh! It’s quite obvious, with hindsight!
I added in a line to print
debug_backtrace()and found the code that triggers the populations of the tablemap. This eventually showed that the use ofTestOrganiserPeertriggers Propel’s autoloader, and when a peer class is loaded, this in turn results in an immediate call toBaseTestOrganiserPeer::buildTableMap().