5 コレクション仕様
コレクション仕様は、コレクション・オブジェクトの基礎となるOracle Databaseの表またはビューに関する情報を提供するJSONオブジェクトです。コレクションを作成するときに、表またはビューが作成されます。
注意:
コレクション仕様では、厳密なJSON構文を使用する必要があります。つまり、数値以外の各値を二重引用符で囲む必要があります。
PUT
collectionを使用してコレクションを作成する場合は、リクエスト・ボディとしてコレクション仕様を指定することで、そのコレクションのカスタム・メタデータを設定できます。
既存のコレクションのコレクション・メタデータは、GET
catalog操作の一部として返されます。
例5-1に、デフォルトのコレクション・メタデータを指定するコレクション仕様を示します。
表5-1に、コレクション仕様のフィールドおよび使用可能な値を説明します。
注意:
オプション列(作成日のタイム・スタンプ、最終変更タイム・スタンプ、バージョンまたはメディア・タイプ)のいずれかをコレクション仕様から省略した場合、その列は作成されません。少なくとも、コレクションにはキー列とコンテンツ列があります。
表5-1 コレクション仕様のフィールド
フィールド | 説明 | 使用可能な値 |
---|---|---|
|
コレクション・オブジェクトの基礎となる表またはビューを所有するデータベース・スキーマ(ユーザー・アカウント)のSQL名。 |
— |
|
コレクション・オブジェクトの基礎となる表またはビューのSQL名。 |
— |
|
キー列の名前。 |
デフォルト: |
|
キー列のSQLデータ型。 |
|
|
データ型が |
デフォルト: 255 |
|
キーの割当て方法。 |
|
|
|
既存のデータベース順序の名前 |
|
コンテンツ列の名前。 |
デフォルト: |
|
コンテンツ列のSQLデータ型。 |
|
|
データ型がLOBではない場合のコンテンツ列の最大長。 |
デフォルト長は4000バイトです。 |
|
コンテンツ列の検証レベル。SQL条件の
|
|
|
コンテンツ列に格納されるSecureFilesの圧縮レベル。 |
|
|
コンテンツ列に格納されるSecureFilesのキャッシング。 |
|
|
コンテンツ列に格納されるSecureFilesの暗号化アルゴリズム。脚注 1 |
|
|
オプションの作成日のタイム・スタンプ列の名前。 この列はSQLデータ型 |
デフォルト: |
|
オプションの最終変更タイム・スタンプ列の名前。 この列はSQLデータ型 |
デフォルト: |
|
タイムスタンプ列の一意でないインデックスの名前。名前が指定されている場合、インデックスが作成されます。 |
|
|
オプションのバージョン(ETag)列の名前。 この列は、そのメソッドが 注意: メソッドが |
デフォルト: |
|
バージョン管理方法。 |
|
|
オプションのオブジェクトのメディア・タイプ列の名前。 この列は、SQLデータ型 |
|
|
読取り/書込みポリシー: |
|
脚注1
SecureFile暗号化でコレクションを作成する前に暗号化ウォレットを設定します。ALTER
SYSTEM
文のSET
ENCRYPTION
WALLET
句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
例5-1 デフォルトのコレクション・メタデータ
{
"schemaName" : "mySchemaName",
"tableName" : "myTableName",
"keyColumn" :
{
"name" : "ID",
"sqlType" : "VARCHAR2",
"maxLength" : 255,
"assignmentMethod" : "UUID"
},
"contentColumn" :
{
"name" : "JSON_DOCUMENT",
"sqlType" : "BLOB",
"compress" : "NONE",
"cache" : true,
"encrypt" : "NONE",
"validation" : "STANDARD"
},
"versionColumn" :
{
"name" : "VERSION",
"method" : "SHA256"
},
"lastModifiedColumn" :
{
"name" : "LAST_MODIFIED"
},
"creationTimeColumn" :
{
"name" : "CREATED_ON"
},
"readOnly" : false
}
関連項目:
-
SQL条件
is json
によって使用される構文の可能性の詳細は、『Oracle Database JSON開発者ガイド』を参照 -
JSON RFC 4627標準については、
http://tools.ietf.org/html/rfc4627
を参照 -
SecureFiles LOB記憶域の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照
- キーの割当て方法
キーの割当て方法は、コレクションに挿入されたオブジェクトにどのようにキーを割り当てるかを決定します。 - バージョン管理方法
バージョン管理方法は、オブジェクトがコレクションに挿入またはコレクション内のオブジェクトが置換されたとき、RESTサーバーがオブジェクトのバージョン値を計算する方法を決定します。
関連項目
5.1 キーの割当て方法
キーの割当て方法は、コレクションに挿入されたオブジェクトにどのようにキーを割り当てるかを決定します。
表5-2 キーの割当て方法
方法 | 説明 |
---|---|
|
キーはデータベース順序によって生成される整数です。 |
|
キーはSQL関数 |
|
キーはRESTサーバーが実行中のJava仮想マシン(JVM)の組込みの |
|
キーはクライアント・アプリケーションによって割り当てられます(非推奨)。 |
Oracle RESTの標準として、サーバーによって割り当てられるキーを使用すること、つまり、CLIENT
によるキーの割当て方法を避けることを強くお薦めします。簡易な数値のキーが必要な場合は、SEQUENCE
をお薦めします。一意の識別子なら何でもよい場合は、UUID
をお薦めします。
キー割当て方法がSEQUENCE
、GUID
またはUUID
の場合は、操作POST objectを使用してコレクションにオブジェクトを挿入します。RESTサーバーでは、必ずPOST
が挿入操作として解釈され、キーが割り当てられ、レスポンス・ボディでそのキーが返されます。
キーの割当て方法がCLIENT
の場合、URLパスに必要なキーが含まれていないため、POST
をコレクションへのオブジェクトの挿入に使用できません。かわりに、PUT objectを使用してコレクションにオブジェクトを挿入する必要があります。オブジェクトがコレクションにまだ存在しない場合、RESTサーバーでは、PUT
は挿入操作と解釈されます。オブジェクトがコレクションにすでに存在する場合は、RESTサーバーによりPUT
は置換操作と解釈されます。PUT
は、事実上、SQL文のMERGE
と等価です。
注意:
クライアント割当てキーが使用され、キー列タイプがVARCHAR2
の場合、データベース・キャラクタ・セットにはAL32UTF8が推奨されます。これにより、キーからデータベース・キャラクタ・セットへの変換がロスレスになります。
それ以外の場合、クライアント割当てキーにデータベース・キャラクタ・セットでサポートされない文字が含まれる場合、読取りまたは書込み操作時に、データベース・キャラクタ・セットへのキーの変換は失われます。これにより、挿入操作中に重複キー・エラーが発生することがあります。もっと一般的に言うと、予測できない結果が生じることがあります。たとえば、読取り操作で、予定したキーとは異なるキーに関連付けられている値が返されることがあります。
関連項目
親トピック: コレクション仕様
5.2 バージョン管理方法
バージョン管理方法は、オブジェクトがコレクションに挿入またはコレクション内のオブジェクトが置換されたとき、RESTサーバーがオブジェクトのバージョン値を計算する方法を決定します。
表5-3 バージョン管理方法
方法 | 説明 |
---|---|
|
RESTサーバーにより、オブジェクトのコンテンツの各バイトのMD5チェックサムが計算されます。文字データ型( 一括挿入の場合、リクエスト・ボディはオブジェクトの配列として解析され、個別のオブジェクトのバイトは、記憶域用に選択されたエンコーディングにかかわらず、UTF-8エンコーディングで再シリアライズされます。 すべての場合において、各バイトのチェックサムが計算され、オブジェクトの |
|
RESTサーバーにより、オブジェクトのコンテンツの各バイトのSHA256チェックサムが計算されます。文字データ型( 一括挿入の場合、リクエスト・ボディはオブジェクトの配列として解析され、個別のオブジェクトのバイトは、記憶域用に選択されたエンコーディングにかかわらず、UTF-8エンコーディングで再シリアライズされます。 すべての場合において、各バイトのチェックサムが計算され、特定のオブジェクトの |
|
オブジェクトのコンテンツは無視して、オブジェクトの挿入、およびすべての置換操作において(置換操作がオブジェクトのコンテンツを変更しない場合でも)、RESTサーバーにより32文字の16進値である汎用一意識別子(UUID)が生成されます。 |
|
オブジェクトのコンテンツは無視して、RESTサーバーにより、SQLの |
|
オブジェクトのコンテンツは無視して、RESTサーバーにより、オブジェクトが挿入されたときにバージョン1が割り当てられ、オブジェクトが置換されるたびにバージョン値がインクリメントされます。 |
|
RESTサーバーでは、挿入または置換操作の間にバージョン値が割り当てられません。GET操作では、バージョン列に格納されている任意の非nullの値がETagとして使用されます。アプリケーションは、バージョン列に値を入れる責任があります(たとえば、PL/SQLトリガーまたは非同期プログラムを使用して)。 |
コンテンツ自体が変更したときに変更されるMD5
やSHA256
のチェックサム計算値により、クライアントのキャッシュを無効にするための非常に正確な方法が提供されます。しかし、RESTサーバーでは、挿入または置換されたオブジェクトに対してバイト単位で計算を実行しなければならず、コストが高くなります。
UUID
は、RESTサーバーで入力のすべてのバイトを調べたり、SQLが関数の値を戻すのを待つ必要がないため、入力操作として最も効率的です。しかし、オブジェクトのコンテンツを変更しない場合でも、置換操作によりキャッシュされたコピーが無効になります。
TIMESTAMP
は、整数値を必要とするか、または最新のものを決定するために2つのバージョンを比較しなければならない場合に便利です。UUID
と同様、オブジェクトのコンテンツを変更しなくても、置換操作によりキャッシュされたコピーが無効になります。システム・クロックの精度に制限があることから、オブジェクトが非常に高い頻度(ミリ秒ごとに何度も)で変更される可能性がある場合は、TIMESTAMP
はお薦めしません。
SEQUENTIAL
もまた、整数値を必要とするか、または最新のものを決定するために2つのバージョンを比較しなければならない場合に便利です。バージョン値は人が見てわかりやすく、システム・クロックの制限があってもバージョンが増加します。しかし、インクリメント操作がSQL内で発生するため、新規のバージョン値がRESTのレスポンス・ボディで戻され、常に使用できるとはかぎりません。
親トピック: コレクション仕様