xPDOObjectの機能:: save（）メソッド+トランザクション

最近、Sergey Prokhorov別名proxyfabioは記事Validation of objects + transactionを書きました。 このトピックについては、ここで少し説明しました 。 このトピックは非常に重要であり、今日、MODX Revolutionでの大規模プロジェクトの開発における最も重要な問題の1つであることを自分で付け加えたいと思います。

ここでは、「大規模なプロジェクトを実行している場合、MODXでそれらを実行しないでください。何とか何とかしてください。」のようなことを始めないようにすぐにお願いします。 MODXだけでなく、大規模なプロジェクトを行いました。 MODXで大規模なプロジェクトを作成することは非常に可能です。現在、個々のプロジェクトで決定している弱点は2、3だけです。それ以外の場合、MODXは大規模プロジェクトの開発に98％適しています。

したがって、これらの深刻な問題の1つは、xPDOObject :: save（）メソッド（xPDOオブジェクトの保存時に呼び出される）に関連しています。 この問題の本質は、内部で関連オブジェクトxPDOObject :: _ saveRelatedObjects（）を2回保存するメソッドがトリガーされることです。 1 つと2つ 。 これは、これらの関連オブジェクトのプライマリキーとセカンダリキーを設定するために行われます（Ilya Utkinの参考資料を参照 ）。 例でさらに詳しく説明します。 コードは次のとおりです。

<?php $user_data = array( "username" => "test", ); $profile_data = array(); $user = $modx->newObject('modUser', $user_data); $user->Profile = $modx->newObject('modUserProfile', $profile_data); $user->save(); print '<pre>'; print_r($user->toArray()); print_r($user->Profile->toArray()); 

一般に、確かに、このコードの本質は多くの人に明らかですが、詳細に焦点を当てましょう。 2つの新しいオブジェクト（$ userと$ user-> Profile）を作成したとき、それらは保存されるまで識別子を持ちません。 ただし、$ userオブジェクトのみを保存すると、保存された$ user-> Profileオブジェクトも取得されます。 これは、そうであったように、理由も理解できます、イリヤは彼の記事でこれをすべて説明します。 しかし、たまりにくい質問は、「xPDOはどのように「idを$ modx-> Profile-> internalKeyとして割り当てるために$ userオブジェクトがどのIDであるか」をどのように知っているのか」です。 これを行うには、xPDO :: save（）メソッドのコードをもう一度見てみましょう。

ここでは、$ user-> _ saveRelatedObjects（）メソッドの最初の呼び出しがあります 。 この時点では、$ユーザーオブジェクトはまだ保存されておらず（データベースに書き込まれていません）、まだIDがありません。 $ user-> Profileも保存されず、idもinternalKeyもありません。 $ user-> _ saveRelatedObjects（）メソッドの呼び出しを見ると、 関連オブジェクトが列挙および保存されていることがわかります （xPDO :: _ saveRelatedObject（）メソッド）。 ここで、$ user-> Profileオブジェクトが関連付けられている$ userオブジェクトを保存していることをもう一度明確にします。 そして、実際には、$ user-> Profileオブジェクトは$ userオブジェクトよりも前に保存されることがわかります。 なんで？ 呼び出しで$ user-> _ saveRelatedObject（$ user-> Profile） メソッド$ user-> Profile-> save（ ）が呼び出され 、現在$ user-> Profileに関連するオブジェクトがないため、書き込まれますデータベースに。 そして、ここで何を得るのでしょうか？ $ user->プロファイルはすでに保存されており、独自のidを持っていますが、$ userオブジェクトにはidがありません（まだ保存されていないため）。 このため、セカンダリキー$ user-> Profile-> internalKeyはまだ空です。

OK、私たちはそれを理解しました、私たちは続けています。 そして、$ユーザーオブジェクト自体を保存し、データベースに書き込み、IDを割り当てます。 以上で、記録は完了です。 これで両方のid-shnikiができましたが、まだ$ user-> Profile-> internalKeyの値はありません。 これは、まさに$ user-> _ saveRelatedObjects（）メソッドがもう一度呼び出されるものです。 これで、関連付けられた$ user-> Profileオブジェクトが保存されると、$ user-> idの値を取得し、$ user-> Profile-> internalKeyとして割り当てて保存できるようになります。

はい、私はこれらすべてが非常に紛らわしいことに同意します（そして、私はそれをさらにもっと紛らわしいと説明します）が、このすべてに論理があります。 そして実際、この理由から、innoDBの代わりにMyIsamを永続的に使用していることがわかります。 なんで？ はい、innoDBでは完全に動作することができないためです。 そして今、私たちは仕事の原理ではなく、既存の問題を分析します。 このすべてを完全に理解するには、MySQLを十分に理解する必要があります。つまり、トランザクション、プライマリキー、外部キーなどを理解する必要があります。

データベースをさらに正しく構成しましょう。つまり、データベース自体のレベルでプライマリキーとセカンダリキーを構成します。 これを行うには、次を実行します。



2. modx_usersテーブルでは、idフィールドはint（10）unsignedであり、modx_users_attributesでは、internalKeyフィールドはint（10）（unsignedではありません）です。 このため、両方のテーブルの列のデータ型が完全に一致する必要があるため、セカンダリキーを単純に構成することはできません。




セカンダリキーの保存中にエラーが発生しなかった場合は、すばらしいです！ しかし、あなたが得るかもしれないいくつかの間違いがあります。 最も一般的なものは次のとおりです。
1.データ型が一致しません。
2.セカンダリレコードの場合、プライマリレコードはありません（たとえば、internalKey = 5のmodx_user_attributesにレコードがありますが、id = 5のmodx_usersにはレコードがありません）。

次に、問題の本質を例で見てみましょう。 これを行うには、 コンソールで次のコードを実行します。

 <?php $user_data = array( "username" => "test_". rand(1,100000), ); $profile_data = array( "email" => "test@local.host", ); $user = $modx->newObject('modUser', $user_data); $user->Profile = $modx->newObject('modUserProfile', $profile_data); $user->save(); print '<pre>'; print_r($user->toArray()); print_r($user->Profile->toArray()); 

これで問題は発生していません。すべてコメントなしで保存されました。

それでは、コードを少し変更しましょう。

 <?php $user_data = array( "username" => "test_". rand(1,100000), ); $profile_data = array( "email" => "test@local.host", ); $user = $modx->newObject('modUser', $user_data); $user->Profile = $modx->newObject('modUserProfile', $profile_data); //   id  .     - id, ,      . $user->id = 40; $user->save(); print '<pre>'; print_r($user->toArray()); print_r($user->Profile->toArray()); 

このコードを実行するとどうなりますか？

1. SQLエラーメッセージ

 Array ( [0] => 23000 [1] => 1452 [2] => Cannot add or update a child row: a foreign key constraint fails (`shopmodxbox_test2`.`modx_user_attributes`, CONSTRAINT `modx_user_attributes_ibfk_1` FOREIGN KEY (`internalKey`) REFERENCES `modx_users` (`id`)) ) 

2.両方のオブジェクトはまだ保持されており、正しいidとinternalKeyを持っています。

なぜこれが起こっているのですか？ セカンダリオブジェクトを保存するとき、xPDO はプライマリキー値が存在するかどうかを確認し、存在する場合のみ、その値をセカンダリキーとして既に設定し、このオブジェクトを保存します。 この場合、プライマリキーIDとセカンダリオブジェクトを手動で指定して値を取得し、データベースへの書き込みを試みましたが、実際にはプライマリレコードがないため、プライマリオブジェクトなしではセカンダリレコードを書き込むことができないというSQLエラーが発生します。 しかし、主要なオブジェクトの保存はそこで止まりません。 その後、プライマリ$ userオブジェクトがデータベースに正常に書き込まれ、関連付けられた$ user-> Profileオブジェクトを再度保存しようとすると、プライマリレコードがあるため、すべてが通常保存されます。

これらすべてから、2つの結論が導かれます。

1.関連オブジェクトを保存する場合、セカンダリオブジェクトの保存中のエラーを追跡し、何らかの方法でそれらに反応することはできません。 つまり、セカンダリオブジェクトが保存されなかった理由（プライマリオブジェクトがまだないかどうか、xPDOObject :: _ saveRelatedObjects（）メソッドが再度呼び出されたとき、またはそこで一意のキーがクラッシュしたかどうか、原則として、マップレベルでの検証に合格しなかったかどうかなど、記録を記録することはできません）。

2.このため、トランザクションを完全に使用することは不可能です。

この問題を解決する可能な方法。

関連オブジェクトのタイプに応じて、xPDOObject :: _ saveRelatedObjects（）メソッドの1回目と2回目の呼び出しを区別することで、この問題の解決策がわかります。つまり、最初の呼び出しはプライマリオブジェクト、2番目の呼び出しはセカンダリです。 この場合、キーとの混同は絶対にありません。オブジェクトが何らかの理由で保存されなかった場合、これは間違いなくエラーを意味し、保存プロセス（トランザクションのロールバックを含む）を中断することが可能になります。