Brownさんによるトランザクションについてのシリーズ記事の第4回、マジックキーを使った手法を紹介します。シリーズの他の記事も合わせてご参照ください。動作するシステムには不可欠の機能です。私はしばらくこの話をしていないので、今言います。スクリプト化されたプロセスが一度に複数のレコードを更新(作成、編集、削除)する場合、トランザクションは必須です。ひとまとまりのエンティティ(たとえば、請求書と請求明細など)を何らかの方法で追加または変更する場合、データベーストランザクションは必須です。今までにポータルを使用する方法を見てきましたが、他の方法でも可能です。それが、ポータルを使わないFileMakerトランザクションです。前回の記事で見たように、ポータルはデバッグや表示には適していますが、必須ではありません。FileMakerでのチャットが私の日課です)で、トランザクションについてこう言いました。「私はトランザクション処理を行うときはレイアウトオブジェクトを使わないようにしています。」これは面白い考えです。レイアウトオブジェクトはユーザが画面でデータを操作するためのものです。スクリプトによる処理では、レイアウトオブジェクトを必要としません。FileMakerはトランザクションに対応しているので、あるマジックを使って空白のレイアウトからトランザクションを実行することができます。それでは、ポータルなしでFileMakerのトランザクションを実行する方法を見ていきましょう。Irvineは優秀なFileMaker開発者です。DevConでの彼の講演時間をチェックしてください。最初から始める開始コンテキストをもう一度見てみましょう。今回の例では、DBTransactionsテーブルオカレンスに基づいた、同じ名前のDBTransactionsレイアウトです。以下を参照してください。我々は前回と同じDBTransactionsレイアウトにいます。データはまとめられ、JSONオブジェクトとしてフィールドに格納されています。テーブルDBTransactionsとOrderの間、およびDBTransactionsとOrderItemの間のそれぞれにリレーションが設定させています。どちらも「リレーションを使用したレコードの作成を許可する」がオンに設定されています。orderIDとOrderテーブルの主キーを使用してリレーションが生成されます。OrderItemについても同様の設定です。DBTransactionsのこれら2つのフィールドは、レイアウト上に表示されています(かならずしも表示されている必要はありませんが)。これで準備ができました。ポイントはこここのトランザクション処理の鍵は、ポータルと同じ方法で処理していることです。レコードをリレーションを介して作成しています。レコードを作成/編集するためにポータルを介することはありません。代わりに、リレーションを使ってフィールドを設定するだけです。Itemレコードを作成できます。ここで少し休んで、しばらく考えてみましょう。(私はこの動作を初めて見たとき、とても驚きました。)そしてもう一つ最初に設定したリレーションについて説明し、それについての考え方を確認しましょう。下の図に示すように、OrderとのリレーションはOrderIdフィールドとOrderテーブルの主キーの間に設定されます。これは通常とは異なります。通常は主キーから外部キーにデータが流れます。このリレーションはトランザクション処理に不可欠です。そのテーブルに一つレコードを作成するたびに、関連するリレーションで1つのユニークなレコードが必要です。通常の主キーから外部キーへのリレーションの設定では、(ポータルを使う手法が示すように)複数の関連レコードがあります。今回それはできません。そこで、マジックキーの手法を活用して、作成された各レコードとのリレーションを設定します。Frankのブログ記事を参照してください。ポータルを使わないFileMakerのトランザクションスクリプトは以下の通りです。Orderレコードを作成するこのステップでは、Orderテーブルのフィールドに、今回の例ではJSONオブジェクトの値を設定します。OrderIDに戻ります。DBTransactionsとOrderレコードの間のリレーションは有効です。Orderレコードの他のフィールドの設定を開始できます。レコードがたった今作成されたので、開いているレコード数は0から2になりました。Itemレコードは、ほとんど同じように作成されます。Item::amountフィールドの値とそれに対応する値を設定します。実際にフィールドに値を設定する前に行うことを確認してください。このフィールドが設定されると、OrderLineレコードの主キーがDBTransactionsテーブルに戻ります。Itemレコードとのリレーションは有効です。開いているレコードは3つです。Itemレコードを作成するポータルを使わないFileMakerのトランザクションでは、ここでわけが分からなくなるので、ちょっと一時停止して次に何が起こるのか考えてみましょう。Itemは作成されるでしょうか?答えはNoです。Itemはまだ作成されていません。Itemレコードへのリレーションがまだ残っているためです。Itemの情報を設定すると、最初のレコードのデータが上書きされます。そのためには、DBTransactions::orderItemIDフィールドを消去します。これではレコードをコミットしてしまいませんか?コミットはしません。なんらかのマジックによって、FileMakerはそのレコードをメモリに保存します。そのレコードを見ることもアクセスすることもできませんが、FileMakerが確かにそのレコードをコミットせずに開いています。これでOrderItemIdフィールドがクリアされたので、リレーションを介して2番目のレコードを作成できます。この時点で4つのレコードが開いた状態です。2}}そして、リレーションを介してすべてのレコードが作成されるまでこれを続けます。今回の例では処理の終わりまでに、6つのレコードを開きます。4}}トランザクションを終了させるまで、これらを開いたままにします(次回に続く)。リレーションを介してトランザクションを実行する開始コンテキストとレコードの間のリレーションを壊しても、FileMakerがすべてのレコードを開いてメモリ内に保持できるのは、とてもクールです。これを初めて見たとき、私は本当に驚きました。それまで、レコードを作成するためにはポータルが必要だと思っていました。FileMakerのトランザクションは、ポータルなしで実行できるのです。いくつか欠点はあります。ひとつは、作成されたレコードを見ることができません。レコードが作成されたことはちゃんと確認できます。開いていても、見ることができません。二つ目は..いや、他に欠点を見つけることができません。この手法では、レコードを作成するためのUIオブジェクト(ポータル)をなくことができます。これは他のアクションと一貫性があります。レイアウト上にフィールドがなくてもフィールドに値を設定できます。この手法を試してみることをお勧めします。ポータルなしでFileMakerトランザクションを実行してみてください。オブジェクトやその設定をすべてスキップし、レコードを処理するためにFileMakerに元から備わっている機能を使用するのです。Karbonはこのように機能し、レコード処理をすべてトランザクションで行います。