なぜDoctrineオブジェクトのvar_dumpがApacheを殺すのですか?
質問
非常に奇妙な問題があります。Doctrineオブジェクトを var_dump
(または print_r
)しようとすると、空の空白ページ(200 OKヘッダー)でApacheが応答します。次のような通常のphp変数を var_dump
できます:
$dummy = array("a" => 1, "b" =>2);
そしてそれは正常に動作します。しかし、Doctrineクラスのオブジェクト( $ connection-> query()
の結果、またはDoctrineのオブジェクトモデルのクラスのインスタンス)を使用することはできません。
誰がこれが起こるのか知っていますか?
解決
自己参照オブジェクトを print_r()
しようとすると、ループが発生してメモリ不足になることがありました。おそらくそれがあなたに起こっていることです。
メモリ制限( ini_set( 'memory_limit'、 '256M');
)を増やしてみて、それで修正されるかどうかを確認してください。
編集:これに対する実際の修正があるとは思わない-再帰の深さを制限しない(またはしないでください)PHPの内部 var_dump
/ print_r
少なくとも適切に実行してください)。 XDebug 拡張機能をインストールすると、組み込みの var_dump
をバージョンに置き換えることができます再帰をはるかにうまく処理します。
他のヒント
遅延ロードプロキシには、DoctrineのEntityManagerのインスタンスとそのすべての依存関係が常に含まれます。
したがって、 var_dump
は、レンダリングおよび読み取りが不可能な非常に大きな再帰構造をダンプする可能性があります。ダンプを人間が読めるレベルに制限するには、 \ Doctrine \ Common \ Util \ Debug :: dump()
を使用する必要があります。この関数のデフォルトの深さは2(2番目のパラメーター)に設定されていることに注意してください
Doctrine_Record クラスの toArray
メソッドを使用します
var_dump($doctrine_record->toArray());
DBフィールドのみを表示し、完全なDoctrine内部(自己参照/再帰btwを含む)のダンプを回避します
オブジェクトがDoctrine_Collectionのインスタンスであることが確実な場合、toArrayを使用できます。 Xdebugは教義の記録には役立ちません。
私が提案する方法は、オブジェクトを印刷するカスタム再帰関数を実装することです。この関数は、ニード時にDoctrine_Record :: toArray()を使用します
function var_dump_improved()
{
foreach (func_get_args() as $arg) {
if ($args instanceof Doctrine_Collection) {
print_r($arg);
} else if ( $arg instanceof Traversable || is_array($arg) ) {
// do a foreach and recall var_dump_improved on subelements
} else if (...) {
// other types
}
}
}
最大入れ子レベルでデバッグする再帰関数がいくつかあります
http://php.net/manual/en/function.var- dump.php
コメントを見て、「再帰」を探します