0

私はオンラインでかなりの調査をテストして行いましたが、それでも運がありません。誰かがこの問題に遭遇したことがありますか？

たとえば、次のように教義クエリを設定しました。

$q = Doctrine_Query::create()
->update('PckFolder')
->set('id_path', "CONCAT(?, RIGHT(id_path, LENGTH(id_path)-?))", array($newPath, $lenOld))
->where("id_path like '$oldPath%'");

// and I print the query out
$qstr = $q->getSqlQuery(array($newPath, $lenOld));

私に与える代わりに：

UPDATE pck_folder SET id_path = CONCAT(?, RIGHT(id_path, LENGTH(id_path)-?)) WHERE (id_path like '1/2//%')

教義は私に与えました：

UPDATE pck_folder SET id_path = CONCAT(?, RIGHT(id_path, LENGTH(id_path-?))) WHERE (id_path like '1/2//%')

この部分に注意してくださいRIGHT(id_path, LENGTH(id_path)-?)

4

1 に答える 1

1

（注：Doctrine1.2を使用していることを前提としています。まだDoctrine2.0を使用していません。）

私は以前にその特定のバグに遭遇したことはありませんでしたが、Doctrine_Queryでのupdate（）の実装に多くの問題を発見しました。基本的に、最も単純な更新クエリ以外は、パーサーが間違ったクエリまたは無効なクエリを生成する原因になります。たとえば、更新内の副選択を処理することはできません。

Raw SQLクエリを作成するか、効率は低下しますが完全に機能する回避策を使用してください。Doctrine_Queryを使用して更新するレコードを選択し、それらを繰り返し処理してPHPでフィールドを設定し、各レコードでsave（）を呼び出します。

ちなみに、UPDATEクエリとDoctrineの使用に固有の大きなGOTCHAがあり、とにかく多くの場合、その回避策を使用するように強制されます。つまり、ユーザーまたはプラグインがモデル内で気の利いたDoctrineフックメソッドを使用しているが、それらのレコードに影響を与えるSQLレベルの更新を実行すると、フックは黙って回避されます。アプリケーションによっては、ビジネスロジックの処理が失敗する可能性があります。

于 2012-04-12T15:37:03.460 に答える