レガシー命令コード

項目一覧

OP_DELETE

OP_GET_MORE
OP_INSERT
OP_KILL_CURSORS
OP_QUERY
OP_REPly
OP_UPDATE

このページでは、MongoDB でサポートされなくなったレガシー命令コードについて説明します。これらのレガシー命令コードは次のとおりです。

MongoDB 5.0 以降、非推奨になりました。
MongoDB 5.1 以降ではサポートされていません。

MongoDB 5.1以降では、MongoDB サーバーにリクエストを送信するための命令コードは、 OP_MSGとOP_COMPRESSEDのみです。

OP_DELETE

OP_DELETE メッセージは、コレクションから 1 つ以上のドキュメントを削除するために使用されます。 OP_DELETE メッセージの形式は次のとおりです。

struct {
    MsgHeader header;             // standard message header
    int32     ZERO;               // 0 - reserved for future use
    cstring   fullCollectionName; // "dbname.collectionname"
    int32     flags;              // bit values - see below for details.
    document  selector;           // query object.  See below for details.
}

フィールド	説明
`header`	メッセージヘッダー。標準メッセージヘッダーを参照してください。
`ZERO`	0 の整数値です。将来の使用のために予約されています。
`fullCollectionName`	完全なコレクション名、具体的にはその名前空間。名前空間は、データベース名とコレクション名を連結したもので、連結に`.`を使用します。たとえば、データベース`test`とコレクション`contacts`の場合、完全なコレクション名は`test.contacts`です。
`flags`	操作のビット値: ビット値は以下に対応します。 `0` は、 SingleRemove に対応します。これが設定されている場合、データベースはコレクション内の最初に一致するドキュメントのみを削除します。そうでない場合、一致するすべてのドキュメントが削除されます。 `1`- `31`は予約されています。 0 に設定する必要があります。
`selector`	削除するドキュメントを選択するために使用されたクエリを表す BSON document セレクターには 1 つ以上の要素が含まれており、コレクションから削除されるドキュメントはすべて一致する必要があります。

OP_DELETE メッセージには応答しません。

OP_GET_MORE

OP_GET_MORE メッセージは、コレクション内のドキュメントをデータベースでクエリするために使用されます。 OP_GET_MORE メッセージの形式は次のとおりです。

struct {
    MsgHeader header;             // standard message header
    int32     ZERO;               // 0 - reserved for future use
    cstring   fullCollectionName; // "dbname.collectionname"
    int32     numberToReturn;     // number of documents to return
    int64     cursorID;           // cursorID from the OP_REPLY
}

フィールド	説明
`header`	メッセージヘッダー。標準メッセージヘッダーを参照してください。
`ZERO`	0 の整数値です。将来の使用のために予約されています。
`fullCollectionName`	完全なコレクション名、具体的にはその名前空間。名前空間は、データベース名とコレクション名を連結したもので、連結に`.`を使用します。たとえば、データベース`test`とコレクション`contacts`の場合、完全なコレクション名は`test.contacts`です。
`numberToReturn`	クエリへの最初の OP_REPlyメッセージのドキュメント数を制限します。ただし、 `numberToReturn`を超える結果がある場合は、データベースによりカーソルが確立され、 `cursorID`がクライアントに返されます。クライアントドライバーが「制限」機能（SQL の LIT キーワードなど）を提供する場合、指定された数以上のドキュメントが呼び出し元のアプリケーションに返されないようにするかは、クライアントドライバーの判断となります。 `numberToReturn`がの場合: `0`の場合、データベースはデフォルトの戻りサイズを使用します。負の場合、データベースはその数値を返し、カーソルを閉じます。そのクエリのそれ以上の結果は取得できません。 `1`、サーバーは値を`-1`として扱います（カーソルを自動的に閉じます）。
`cursorID`	OP_REPlyで取得されたカーソル識別子です。これは、データベースから取得された値である必要があります。

データベースは、OP_REPly メッセージとともにOP_GET_MOREメッセージに応答します。

OP_INSERT

OP_INSERT メッセージは、1 つ以上のドキュメントをコレクションに挿入するために使用されます。 OP_INSERT メッセージの形式は次のとおりです。

struct {
    MsgHeader header;             // standard message header
    int32     flags;              // bit values - see below
    cstring   fullCollectionName; // "dbname.collectionname"
    document* documents;          // one or more documents to insert into the collection
}

フィールド	説明
`header`	メッセージヘッダー。標準メッセージヘッダーを参照してください。
`flags`	操作のビット値: ビット値は以下に対応します。 `0` は、 ContinueOnError に対応します。これが設定されている場合、データベースは一括挿入の処理を停止しません（たとえば、 ID が重複しているため）。これにより、一括挿入は一連の単一挿入と同様に動作しますが、最後の 1 つだけでなくいずれかの挿入が失敗した場合は lastError が設定されます。複数のエラーが発生した場合、 getLastError によって最新のエラーのみが報告されます。 `1`- `31`は予約されています。 0 に設定する必要があります。
`fullCollectionName`	完全なコレクション名、具体的にはその名前空間。名前空間は、データベース名とコレクション名を連結したもので、連結に`.`を使用します。たとえば、データベース`test`とコレクション`contacts`の場合、完全なコレクション名は`test.contacts`です。
`documents`	コレクションに挿入する 1 つ以上のドキュメント。複数ある場合は、順番にソケットに書込まれます。

OP_INSERT メッセージには応答しません。

OP_KILL_CURSORS

OP_KILL_CURSORS メッセージは、データベース内のアクティブなカーソルを閉じるために使用されます。これは、クエリの最後にデータベースリソースが再利用されるようにするために必要です。 OP_KILL_CURSORS メッセージの形式は次のとおりです。

struct {
    MsgHeader header;            // standard message header
    int32     ZERO;              // 0 - reserved for future use
    int32     numberOfCursorIDs; // number of cursorIDs in message
    int64*    cursorIDs;         // sequence of cursorIDs to close
}

フィールド	説明
`header`	メッセージヘッダー。標準メッセージヘッダーを参照してください。
`ZERO`	0 の整数値です。将来の使用のために予約されています。
`numberOfCursorIDs`	メッセージにあるカーソル ID の数。
`cursorIDs`	閉じるカーソル ID の「配列」。複数ある場合は、順番にソケットに書込まれます。

カーソルが使い果たされるまで読み取られる（ OP_QUERYまたはOP_GET_MOREがカーソル ID に対して 0 を返すまで読み取る）場合、カーソルを強制終了する必要はありません。

OP_QUERY

OP_QUERY メッセージは、コレクション内のドキュメントをデータベースにクエリするために使用されます。 OP_QUERY メッセージの形式は次のとおりです。

struct OP_QUERY {
    MsgHeader header;                 // standard message header
    int32     flags;                  // bit values of query options.  See below for details.
    cstring   fullCollectionName ;    // "dbname.collectionname"
    int32     numberToSkip;           // number of documents to skip
    int32     numberToReturn;         // number of documents to return
                                      //  in the first OP_REPLY batch
    document  query;                  // query object.  See below for details.
  [ document  returnFieldsSelector; ] // Optional. Selector indicating the fields
                                      //  to return.  See below for details.
}

フィールド

説明

header

メッセージヘッダー。標準メッセージヘッダーを参照してください。

flags

操作のビット値: ビット値は以下に対応します。

0 は予約されています。 0 に設定する必要があります。
1 は tailableCursor に対応します。追尾可能（tailable）な意味は、最後のデータが取得されたときにカーソルが閉じられていないことを意味します。あるいは、カーソルは最終オブジェクトの位置をマークします。さらにデータを受信した場合は、カーソルが配置されていた場所から後でカーソルの使用を再開できます。レイテンシカーソルと同様に、カーソルはある時点で無効になる可能性があります（CursorNotFound）。たとえば、参照する最終オブジェクトが削除された場合などです。
2 は、 SlaveOk に対応します。レプリカスレーブのクエリを許可します。通常、これらは名前空間が「local」でない限り、エラーを返します。
3 は、OplogReplace に対応します。 oplog の適格なクエリに対して最適化が自動的に実行されるため、このフラグを指定する必要はありません。詳細については、 oplogReplaceを参照してください。
4 は NoCursorTimeout に対応します。サーバーは通常、非アクティブ期間（10 分）の後にアイドルカーソルをタイムアウトして、過剰なメモリの使用を防ぎます。それを防ぐには、このオプションをに設定します。
5 は、AwaitData に対応します。 tailableCursor と併用します。カーソルがデータの末尾にある場合、データを返さずに、一時的にブロックします。タイムアウト期間が経過すると、サーバーは通常通りデータを返します。
6 使用量に相当します。クライアントがクエリされたすべてのデータを完全に読み取ることを前提として、複数の " more" パッケージでデータを完全にストリーミングします。多くのデータを取得していて、すべてを削減する必要があることがわかっている場合は、より高速になります。注: クライアントは接続を閉じない限り、すべてのデータを読み取れません。
7 は部分に相当します。一部のシャードがダウンした場合（エラーがスローされる代わりに）、 mongos から部分的な結果が取得されます
8- 31は予約されています。 0 に設定する必要があります。

fullCollectionName

完全なコレクション名、具体的にはその名前空間。名前空間は、データベース名とコレクション名を連結したもので、連結に.を使用します。たとえば、データベースtestとコレクションcontactsの場合、完全なコレクション名はtest.contactsです。

numberToSkip

クエリの結果を返すときに、省略するドキュメントの数を設定します - 結果データセットの最初のドキュメントから。

numberToReturn

クエリへの最初のOP_REPlyメッセージのドキュメント数を制限します。ただし、 numberToReturnよりも結果がある場合は、データベースは引き続きカーソルを確立し、 cursorIDをクライアントに返します。クライアントドライバーが「制限」機能（SQL の LIT キーワードなど）を提供する場合、指定された数以上のドキュメントが呼び出し元のアプリケーションに返されないようにするかは、クライアントドライバーの判断となります。

numberToReturnがの場合:

0の場合、データベースはデフォルトの戻りサイズを使用します。
負の場合、データベースはその数値を返し、カーソルを閉じます。そのクエリのそれ以上の結果は取得できません。
1、サーバーは値を-1として扱います（カーソルを自動的に閉じます）。

query

クエリを表す BSON ドキュメント。クエリには 1 つ以上の要素が含まれており、結果セットに含めるドキュメントはすべて一致する必要があります。指定可能な要素には、 $query 、 $orderby 、 $hint 、 $explainなどがあります。

returnFieldsSelector

任意。返されるドキュメントのフィールドを制限する BSON ドキュメント。 returnFieldsSelectorには 1 つ以上の要素が含まれています。各要素は返されるフィールドの名前と、整数値1です。 JSON 表記では、 a 、 b 、 cのフィールドに制限するreturnFieldsSelectorは次のようになります。

{ a : 1, b : 1, c : 1}

データベースは、OP_REPly メッセージを含むOP_QUERYメッセージに応答します。

注意

MongoDB 5.1 では、OP_QUERY 検索操作と OP_QUERY コマンドの両方のサポートが削除されました。例外として、OP_QUERY は、接続ハンドシェイクの一部として hello コマンドと isMaster コマンドの実行は引き続きサポートされます。

OP_REPly

OP_REPLYメッセージは、 OP_QUERYまたはOP_GET_MOREメッセージに応答してデータベースによって送信されます。 OP_REPly メッセージの形式は次のとおりです。

struct {
    MsgHeader header;         // standard message header
    int32     responseFlags;  // bit values - see details below
    int64     cursorID;       // cursor ID if client needs to do get more's
    int32     startingFrom;   // where in the cursor this reply is starting
    int32     numberReturned; // number of documents in the reply
    document* documents;      // documents
}

フィールド	説明
`header`	メッセージヘッダー。標準メッセージヘッダーを参照してください。
`responseFlags`	操作のビット値: ビット値は以下に対応します。 `0` は CursorNotFound に対応します。 `getMore`が呼び出されたが、サーバーでカーソル ID が有効でない場合に設定されます。ゼロの結果が返されます。 `1` は QueryFailure に対応します。クエリが失敗した場合に設定されます。結果は、失敗を説明する "$err" フィールドを含む 1 つのドキュメントで構成されます。 `2` は、 ShardConfigStale に対応します。ドライバーはこれを無視する必要があります。このセットは`mongos`のみに表示されます。その場合、サーバーから構成を更新する必要があります。 `3` は、AwaitCapable に対応します。サーバーが AwaitData Query オプションをサポートしている場合に設定されます。そうでない場合、クライアントは追尾可能 (tailable) カーソルの getMore との間でわずかに休止する必要があります。 `4`- `31`は予約されています。無視します。
`cursorID`	この OP_REPLY が構成要素である`cursorID` 。クエリの結果セットが 1 つの OP_REPly メッセージに収まる場合、 `cursorID`は0になります。この`cursorID`は、より多くのデータを取得するために使用されるOP_GET_MOREメッセージで使用する必要があります。また、 OP_KILL_CURSORSメッセージが不要になった場合は、クライアントによって閉じられる必要があります。
`startingFrom`	カーソル内の開始位置。
`numberReturned`	応答内のドキュメントの数。
`documents`	返されたドキュメント。

OP_UPDATE

OP_UPDATE メッセージは、コレクション内のドキュメントを更新するために使用されます。 OP_UPDATE メッセージの形式は次のとおりです。

struct OP_UPDATE {
    MsgHeader header;             // standard message header
    int32     ZERO;               // 0 - reserved for future use
    cstring   fullCollectionName; // "dbname.collectionname"
    int32     flags;              // bit values. see below
    document  selector;           // the query to select the document
    document  update;             // specification of the update to perform
}

フィールド	説明
`header`	メッセージヘッダー。標準メッセージヘッダーを参照してください。
`ZERO`	0 の整数値です。将来の使用のために予約されています。
`fullCollectionName`	完全なコレクション名、具体的にはその名前空間。名前空間は、データベース名とコレクション名を連結したもので、連結に`.`を使用します。たとえば、データベース`test`とコレクション`contacts`の場合、完全なコレクション名は`test.contacts`です。
`flags`	操作のビット値: ビット値は以下に対応します。 `0` は、アップサートに対応します。これが設定されている場合、一致するドキュメントが見つからない場合、データベースは指定されたオブジェクトをコレクションに挿入します。 `1` は MultiUpdate に対応します。設定すると、データベースはコレクション内の一致するオブジェクトをすべて更新します。それ以外の場合は、最初に一致するドキュメントのみが更新されます。 `2`- `31`は予約されています。 0 に設定する必要があります。
`selector`	更新するドキュメントの選択に対するクエリを指定する BSON ドキュメント。
`update`	実行される更新を指定する BSON ドキュメント。更新の指定の詳細については、更新操作のドキュメントを参照してください。

OP_UPDATE メッセージには応答しません。

戻る

ワイヤプロトコル

mongosh メソッド