2012-04-10 13 views
0

私はかなりの研究をオンラインで行っていますが、まだ運がありません。誰もこの問題に遭遇しましたか?代わりに私を与えるDoctrine - 奇妙な移動括弧がクエリにあります

$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//%') 

Doctrineは私を与えた:

言ってやるが、私は次のように設定教義クエリ持っ

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)-?)

答えて

1

(注:Doctrine 1.2を使用していると仮定しています。私はDoctrine 2.0をまだ使用していません。)

Doctrine_Queryのupdate()の実装には数多くの問題がありました。基本的には、最も簡単な更新クエリではなく、パーサーが間違ったクエリまたは無効なクエリを生成します。たとえば、更新内のサブ選択を処理することはできません。

Raw SQLクエリを書いてみるか、効率的ではありませんが完全に機能しない回避策を使用してください:Doctrine_Queryを使用して更新するレコードを選択し、それらを反復してPHPでフィールドを設定してからsaveそれぞれ。

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

+0

よろしくお願いいたします。 –

関連する問題