変更ビューにサブスクリプションを作成する

提供: InterBase
移動先: 案内検索

変更ビュー へ戻る


データベース接続の自然境界を越えて、テーブルのセット上での変更されたデータの監視に対して関心を設定するには、サブスクリプションが、テーブル(基本テーブルまたはビュー)のリスト上に作成されていなければなりません。


CREATE SUBSCRIPTION の構文

 CREATE SUBSCRIPTION <subscription_name> ON< 
      <table_name>[(column_name_comma_list)][FOR ROW (CHANGE | {INSERT, UPDATE, DELETE})]
      [, <table_name>[(column_name_comma_list)][FOR ROW (CHANGE | {INSERT, UPDATE, DELETE})] ...] 
      [DESCRIPTION user-description];
  • FOR ROW 句は、どのタイプの行変更が、サブスクリプションのために追跡される列レベルの変更を発生させるのかを記述します。
  • FOR ROW 句が省略された場合、動作はデフォルトの FOR ROW (CHANGE) になります。 CHANGE オプションは、INSERTUPDATE のデータ変更オペレーションを追跡し、追跡されている列が値を変更すると即座に行を返します。
  • INSERTUPDATEDELETE が指定された場合、すべての追跡されている列上の変更ステータスが判別されます。 これは、「Deep Record Introspection(詳細レコード調査)」と呼ばれ、CHANGE オプションは「Shallow Record Introspection(簡易レコード調査)」と呼ばれています。 変更ビュー のパフォーマンスは、CHANGE オプションの方が速いことが想定されますが、INSERTUPDATEDELETE の組み合わせの方がより完全な処理になります。DELETE は、明示的に指定されない限り、デフォルトでは追跡されません。
  • すべての追跡列を把握し、どのオペレーションが列の値変更を起こしたかを知る必要がある場合に、Deep Record Introspection が必須となります。
  • Shallow Record Introspection は、1 つまたは複数の列が変更されたか(各追跡列の値がどう変更されたかではなく)、もしくは、値をまったく変更されていないかのみを知る必要のある場合のためのものです。これは、サブスクリプションに関して、行に何らかの変更があったかを示します。
  • テーブルが単独で指定された場合、そのテーブルのすべての列が追跡対象となります。
  • 列のサブセットのみを追跡したい場合、サブスクリプションで、任意の列のリストを指定することができます。 例えば、


CREATE SUBSCRIPTION のサンプル

CREATE SUBSCRIPTION sub_employee_changes ON EMPLOYEE (EMP_NO, DEPT_NO, SALARY) DESCRIPTION  'Subscribe to changes in EMPLOYEE table';
 
CREATE SUBSCRIPTION sub_customer_deletes ON CUSTOMER FOR ROW (DELETE) DESCRIPTION 'Subscribe to deletes in CUSTOMER table';
 
CREATE SUBSCRIPTION sub_various_changes
 ON EMPLOYEE FOR ROW (INSERT, UPDATE, DELETE),
   CUSTOMER FOR ROW (INSERT, UPDATE, DELETE),
   SALES FOR ROW (UPDATE),
   DEPARTMENT (LOCATION) FOR ROW (UPDATE)
 DESCRIPTION 'Subscribe to various changes on multiple tables';

列の任意のリストが EMPLOYEE テーブルに対して指定されており、それら列への変更のみが追跡されています。 FOR ROW 句は EMPLOYEE テーブルに対して指定されていませんので、FOR ROW のデフォルト、CHANGE オプションとなり、サブスクリプションによってすべての挿入、更新、削除の変更が追跡され、あらゆる変更が行を返します。 CUSTOMER テーブル句は、行削除のみが追跡されることを示しています。

DROP SUBSCRIPTION

メモ: この新しい関数は、InterBase XE7 Update 1 より導入されています。

一連の変更ビューの監視に対する関心を解除するには、サブスクリプションをドロップしなければなりません。

  • RESTRICTが指定されている場合、既存のサブスクライバのチェックが実行されます。 サブスクライバがいた場合、サブスクリプションのドロップは行われず、エラーが返されます。
  • CASCADE が指定されている場合、このサブスクリプションのすべてのサブスクライバがドロップされます。
  • RESTRICTCASCADE のどちらも指定されていない場合、RESTRICT が指定されていると想定されます。


DROP SUBSCRIPTION の構文

DROP SUBSCRIPTION <subscription_name> [RESTRICT | CASCADE];

GRANT SUBSCRIBE

ユーザーに、その後、リストされたテーブル群上ので変更を追跡するためにサブスクリプションを登録する、SUBSCRIBE 権限を認可します。


GRANT SUBSCRIBE の構文

GRANT SUBSCRIBE ON SUBSCRIPTION <subscription_name> TO <user_name>;
REVOKE SUBSCRIBE ON SUBSCRIPTION <subscription_name> FROM <user_name>;

SET SUBSCRIPTION

サブスクリプションをアクティブにするには、アプリケーションは、SET SUBSCRIPTION 文を発行しなければなりません。 SET SUBSCRIPTION 文では、複数のサブスクリプションをアクティブにすることができ、AT 句を入れると、対象やデバイス名を、登録された変更通知の受信側として指定することができます。 サブスクライバのユーザー名は、データベース接続のユーザー識別子が暗黙的に使われます。

AT 句を介した、1 ユーザーのための同一スキーマ オブジェクトに対する、複数のサブスクリプションの概念は、2 つのタイプの監視によって動機づけられています:

  • 第1に、1 ユーザーに対する各サブスクリプションは、異なる目的のために異なるときにそれぞれ問い合わされた変更セットに、切断された関心を持つ、数多くのデバイスの中から個別のデバイスを伴います。
  • 第2に、マルチユーザー アプリケーションによっては、プールされたデータベース接続を、単一のユーザー名で使うことがあります(例: CRM_User またときには SYSDBA の場合も)。 これらの場合、変更セットを問い合わせるのにどのサブスクリプションが使用されたか区別するために、代わりの識別子を用意しなければなりません。 その追加識別子は、大まかに、通知先または「デバイス名」とされます。

SET SUBSCRIPTION 文は、サブスクライバに対してサブスクリプションを活性化/非活性化し、コマンドを実行するトランザクションに、そのサブスクリプションをバインドします。 サブスクリプションにおいて、サブスクライブされたすべてのテーブルは、ユーザー レベルのクエリで、それがバインドされたサブスクリプションでトランザクションによって実行される際に、テーブル参照のための変更ビューとして動作します。 トランザクションの終了時、サブスクリプションはバインド解除しなければなりません。つまり、変更ビューがその後も要求される場合には、それに続くトランザクションで SET SUBSCRIPTION を発行する必要があります。

トランザクションのコミット時、サブスクライバのトランザクション状態は更新され、サブスクライバは、コミット後に発生した変更をみることができますが、それ以前のものは見れません。トランザクションのロールバックでは、サブスクライバのトランザクション状態を変更しないままで保持するため、変更ビューで以前の変更が見れますが、新しい変更は見ることができません。トランザクションが、バインドされたサブスクリプションから、いずれのサブスクライブされたテーブルも読み込まなかった場合には、そのサブスクリプションに対する、サブスクライバのトランザクション コンテキストは更新されません。


SET SUBSCRIPTION: 構文と例

SET SUBSCRIPTION [<subscription_name> [, <subscription_name> ...]]  [AT <destination>] {ACTIVE | INACTIVE};
 
SET SUBSCRIPTION sub_employee_changes, sub_customer_deletes AT 'smartphone_123'
 ACTIVE;
 SELECT EMP_NO, DEPT_NO, SALARY FROM EMPLOYEE;
 SELECT * FROM CUSTOMER;
 COMMIT or COMMIT RETAIN;


この例は、2 つのサブスクリプションを活性化し、サブスクライブされたテーブルから変更されたデータ セットを返します。

  • COMMIT は、トランザクションの間、参照されているスキーマ オブジェクトのすべてのサブスクリプションを更新し、最終監視タイムスタンプとトランザクション コンテキストを設定します。
  • COMMIT RETAIN は、最終監視状態を変更せず、通常通り、現在のスナップショットを保持します。 サブスクリプションは、コミット時にトランザクションからバインド解除され、これにより、サブスクライブされたスキーマ オブジェクトに対する、それ以降のクエリはいずれも、変更されたデータの状態にかかわらず、通常のデータセットを返します。 1 つのトランザクションで、任意の数のサブスクリプションを、同時に活性化することができます。

次は: