MongoDB への接続を追加

1. アプリケーションコンソールで、接続ページに移動します。
2. 接続の追加パネルで、追加したい接続のアイコンを選択します。
3. MongoDB アイコンが利用できない場合は、Add More アイコンをクリックしてCData サイトからMongoDB コネクタをダウンロードおよびインストールします。

必須プロパティについては、設定タブを参照してください。

通常必須ではない接続プロパティについては、高度な設定タブを参照してください。

MongoDB への接続

次の接続プロパティを設定し、単一のMongoDB インスタンスに接続します。

• Server：MongoDB インスタンスが実行されているサーバーの名前またはアドレスに設定。ポートはここで指定できます。またはPort で指定します。
• Database：読み書きするデータベースに設定。

DNS シードリストを使用してMongoDB に接続

• Server："mongodb+srv://"" + MongoDB インスタンスが実行されているサーバーの名前に設定。ポートはここで指定できます。またはPort で指定します。
• Database：読み書きするデータベースに設定。
• DNSServer：必要なDNS エントリを解決できるDNSServer のホスト名に設定。

レプリカセットへの接続

レプリカセットに接続するには、前述の接続プロパティに加えて、 次の設定を行います。

• ReplicaSet：アドレスとポートで指定されたレプリカセット内のセカンダリサーバーのカンマ区切りリストに設定。
• SlaveOK：セカンダリ（スレーブ）サーバーから読み出す場合は、これをtrue に設定。
• ReadPreference：これを設定すると、Sync App のセカンダリサーバーからの読み出し方法が微調整されます。

セキュアなMongoDB への接続

UseSSL を設定すると、接続時にSSL/TLS 暗号化をネゴシエートできます。

MongoDB 接続の認証

サポートされているAuthScheme 認証タイプ（MONGODB-CR、SCRAM-SHA-1、SCRAM-SHA-256、PLAIN、GSSAPI）は、チャレンジレスポンス認証とLDAP です。

チャレンジレスポンス

チャレンジレスポンス認証では、User とPassword プロパティは、MongoDB データベースに格納されているユーザー名とパスワードに対応しています。1つのデータベースのデータに接続し、別のデータベースを認証する必要がある場合は、Database とAuthDatabase の両方を設定します。

LDAP

LDAP 認証を使用するには、AuthDatabase を"$external" に設定し、AuthScheme をPLAIN に設定します。この値はSASL PLAIN メカニズムを指定します。このメカニズムは視覚情報をプレーンテキストで送信するため、信頼できないネットワークではTLS/SSL なしでは使用できません。

X.509 証明書

X.509 証明書認証を使用するには、AuthScheme をX509 に設定します。

Amazon DocumentDB クラスターへの接続

Amazon DocumentDB に接続する前に、まずAmazon DocumentDB クラスターと、mongo シェルを含むEC2 インスタンスが実行されていることを確認する必要があります。

次に、EC2 インスタンスへのSSH トンネルを以下のように設定します。

1. AWS 管理コンソールから、［サービス］->［データベース］->［Amazon DocumentDB］を選択します。DocumentDB 管理ページから、［クラスター］を選択して、クラスターをクリックします。
2. ［接続］セクションで、サンプル接続文字列にある--host の値とそのポートに注意してください。
3. ［サービス］->［Compute］->［EC2］に移動します。［実行中のインスタンス］を選択します。
4. インスタンスを選択して、［接続］ボタンをクリックします。
5. ［Example］セクションで、<ami_username>@<Public DNS> の形式で示される、インスタンスとユーザーを識別する値に注意してください。
6. お好みのSSH クライアントで、EC2インスタンスの［接続］ページのHost Name（username@publicDNS）とPort22 を使用して、EC2 インスタンスへの接続を確立します。
7. 認証用に、EC2インスタンスの秘密鍵ファイルを指定します（Putty ではキーを.pem から.ppk に変換する必要があります）。
8. DocumentDB クラスターページのポートとホスト名を使用して、SSH トンネルを構成します。
9. EC2仮想マシンに接続を確立します。

DocumentDB クラスターに接続するには、以下を指定します。

• Server：SSH トンネルをホストしているマシン名に設定。
• Port：SSH トンネルがホストされているポートに設定。
• User：DocumentDB クラスターのプロビジョニングに使用するマスターユーザー名に設定。
• Password：DocumentDB クラスターのプロビジョニング時に設定したマスターパスワードに設定。
• UseSSL：true に設定。
• UseFindAPI：true に設定。

MongoDB API を使用したCosmosDB への接続

MongoDB API を使ってCosmos DB アカウントに接続するために必要な接続文字列を取得するには、Azure Portal にログインして［Azure Cosmos DB］を選択し、自分のアカウントを選択します。［Settings］セクションで、［Connection String］をクリックして次の値を設定します。

• Server：Host 値（アカウント用にプロビジョニングされたサーバーのFQDN）に設定。ポートもここで指定できます。またはPort で指定します。
• Port：ポートに設定。
• Database：読み書きするデータベースに設定。
• User：データベースユーザーに設定。
• Password：ユーザーのパスワードに設定。

Atlas、ObjectRocket、または別のDBaaS プロバイダーに接続する場合は、通常、［接続の確立］に記載されている手順にいくつかのバリエーションがあります。次のセクションでは、いくつかの一般的なサービスに必要な接続プロパティを取得する方法について説明します。

Atlas

MongoDB Atlas には、MongoDB ユーザーまたはLDAP ユーザーで認証できます。次のセクションでは、Atlas 接続文字列をSync App 接続プロパティにマッピングする方法を説明します。Atlas 接続文字列を取得する方法は次のとおりです。

1. Clusters ビューで、接続するクラスタのConnect をクリックします。
2. Connect Your Application をクリックします。
3. いずれかのドライバーオプションを選択すると、接続文字列が表示されます。

前提条件

MongoDB ユーザーの作成および／またはLDAP の設定に加えて、Atlas プロジェクトのホワイトリストに、Sync App が接続しているマシンのIP アドレスが含まれている必要があります。ホワイトリストにIP アドレスを追加するには、［Clusters］ビューで［Security］タブを選択し、［IP Whitelist］->［Add IP Address］をクリックします。

MongoDB ユーザー資格情報

次は、MongoDB ユーザー資格情報を提供する接続文字列の例です。

mongodb://USERNAME:[email protected]:27017,cluster0-shard-00-01.mongodb.net:27017,cluster0-shard-00-02.mongodb.net:27017/test?ssl=true&replicaSet=Cluster0-shard-0&authSource=admin

• AuthScheme：MongoDB バージョン3.0、3.2、3.4、および3.6 に対応するSCRAM-SHA-1。
• Server：レプリカセットの最初のサーバー。あるいは、プライマリまたはセカンダリサーバーを指定できます（Sync App はServer とReplicaSet 内のサーバーをクエリしてプライマリを検索します）。
  

  cluster0-shard-00-00.mongodb.net

• Port：サーバーが稼働しているポート（デフォルトは27017）。
• ReplicaSet：レプリカセット内の他のサーバー。Server とReplicaSet は、MongoDB レプリカセット内のすべてのインスタンスを一緒に指定します。ReplicaSet にサーバー名およびポートを両方指定します。
  

  mycluster0-shard-00-01.mongodb.net:27017,mycluster0-shard-00-02.mongodb.net:27017

• SlaveOK：レプリカセット内のセカンダリ（スレーブ）サーバーからの読み取りを許可する場合は、true。
• AuthDatabase：MongoDB Atlas に接続する場合は、"admin"。Atlas のすべてのMongoDB ユーザーは、管理データベース、すなわち認証データベースに関連付けられています。
• Database：読み書きするデータベース。

• User：MongoDB プロジェクトに追加したMongoDB ユーザーのユーザー名。

• Password：MongoDB ユーザーのパスワード。

• UseSSL：true。Atlas はTLS / SSLを必要とします。

LDAP

次のリストは、LDAP ユーザーで認証するためのMongoDB Atlas の要件を示しています。 以下はMongo クライアントに接続するためのコマンド例です。

mongo "mongodb://cluster0-shard-00-00.mongodb.net:27017,cluster0-shard-00-01.mongodb.net:27017,cluster0-shard-00-02.mongodb.net:27017/test?ssl=true&replicaSet=Cluster0-shard-0&authSource=$external" --authenticationMechanism PLAIN --username cn=rob,cn=Users,dc=atlas-ldaps-01,dc=myteam,dc=com 

• Server：レプリカセットの最初のサーバー。または、別のプライマリまたはセカンダリサーバーを指定できます（Sync App はServer とReplicaSet 内のサーバーをクエリしてプライマリを検索します）。 次に例を示します。
  

  cluster0-shard-00-00.mongodb.net

• Port：サーバーが稼働しているポート（デフォルトは27017）。
• ReplicaSet：レプリカセット内の他のサーバー。Server とReplicaSet は、MongoDB レプリカセット内のすべてのインスタンスを一緒に指定します。 以下に値の例を示します。
  

  mycluster0-shard-00-01.mongodb.net:27017,mycluster0-shard-00-02.mongodb.net:27017

• SlaveOK：レプリカセット内のセカンダリ（スレーブ）サーバーからの読み取りを許可する場合は、true。

• AuthScheme：LDAP 認証のPLAIN。

• Database：読み書きするデータベース。

• AuthDatabase：LDAP ユーザーで認証する場合は、"$external"。

• User：Atlas ユーザー名としてLDAP サーバーにあるユーザーの完全な識別名（DN）。次に例を示します。
  

  cn=rob,cn=Users,dc=atlas-ldaps-01,dc=myteam,dc=com

• Password：LDAP ユーザーのパスワード。

• UseSSL：true。Atlas はTLS / SSLを必要とします。

ObjectRocket

ObjectRocket に接続するには、データベースユーザーの資格情報を使用して認証します。コントロールパネルから必要な接続プロパティを取得できます。［インスタンス］ページでインスタンスを選択し、［接続］メニューを選択してMongoDB 接続文字列を表示します。

前提条件

データベースにユーザーを追加することに加えて、Sync App が接続しているマシンのIP アドレスへのアクセスも許可する必要があります。これを設定するには、［インスタンス］ページでインスタンスを選択し、［Add ACL］をクリックします。

MongoDB ユーザー

mongodb://YOUR_USERNAME:[email protected]:52826,abc123-d4-2.mongo.objectrocket.com:52826,abc123-d4-1.mongo.objectrocket.com:52826/YOUR_DATABASE_NAME?replicaSet=89c04c5db2cf403097d8f2e8ca871a1c

• Server：レプリカセットの最初のサーバー。サーバー名を取得するには、［レプリカセット］をクリックします。または、別のプライマリまたはセカンダリサーバーを指定できます（Sync App はServer とReplicaSet 内のサーバーをクエリしてプライマリを検索します）。
  

  abc123-d4-0.mongo.objectrocket.com

• Port：サーバーが稼働しているポート（デフォルトは27017）。
• ReplicaSet：レプリカセット内の他のサーバー。Server とReplicaSet は、MongoDB レプリカセット内のすべてのインスタンスを一緒に指定します。 以下に値の例を示します。
  

  abc123-d4-2.mongo.objectrocket.com:52826,abc123-d4-1.mongo.objectrocket.com:52826

• Database：読み書きするデータベース。これは、接続しているユーザーの認証データベースでもあることに注意してください。データベースユーザーは、ObjectRocket のデータベース外の他のデータベースと対話することはできません。
• User：Database に定義したMongoDB ユーザーのユーザー名。
• Password：データベースユーザーのパスワード。
• UseSSL：TLS / SSL を有効にする場合は、true。

MongoDB はスキーマレスなドキュメントデータベースで、高いパフォーマンス、使用性、およびスケーラビリティを提供します。これらの機能は、必ずしもSQL-92 のような標準準拠のクエリ言語と互換しないわけではありません。このセクションでは、Sync App が複数のやり方によって、リレーショナルSQL とドキュメントデータベースのギャップの橋渡しをいかに行うかを説明します。

テーブルとしてのMongoDB オブジェクトの操作

Sync App では、スキーマレスなMongoDB オブジェクトをリレーショナルテーブルにモデル化し、SQL クエリをMongoDB クエリに読み替えることで、要求されたデータを取得します。 さまざまなMongoDB 操作がSQL としてどのように表されるかの詳細については、クエリマッピング を参照してください。

スキーマの自動検出

自動スキーマ検出 スキームでは、設定された行数のオブジェクトをスキャンすることで、自動的にMongoDB 内のデータ型を見つけます。MongoDB コレクションのリレーショナル表現をコントロールするためにRowScanDepth、FlattenArrays、およびFlattenObjects を使うことができます。スキーマに結びついていない自由形式クエリ を記述することもできます。

Sync App は、コレクション内のMongoDB ドキュメントをサンプルとして調べ、リレーショナルスキーマを提案します。RowScanDepth プロパティを使って、Sync App がスキャンするドキュメント数を設定することができます。検出プロセスで特定されるカラムはFlattenArrays およびFlattenObjects プロパティに依存します。

オブジェクトのフラット化

FlattenObjects が設定されている場合、すべてのネストされたオブジェクトは連続したカラムにフラット化されます。例えば、次のドキュメントを考えましょう。

{
  id: 12,
  name: "Lohia Manufacturers Inc.",
  address: {street: "Main Street", city: "Chapel Hill", state: "NC"},
  offices: ["Chapel Hill", "London", "New York"],
  annual_revenue: 35,600,000
}

FlattenObjects が設定されていない場合、address.street、address.city、およびaddress.state カラムは別々にはなりません。文字列型の住所カラムは一つのオブジェクトとして表されます。値は次のようになります {street:"Main Street", city:"Chapel Hill", state:"NC"}。JSON アグリゲートの詳細についてはJSON 関数 を参照してください。

配列のフラット化

FlattenArrays プロパティは配列の値をフラット化してそれぞれのカラムとするために使われます。これは次の例のように短い配列の場合にのみ推奨されます。

"coord": [ -73.856077, 40.848447 ]

アンバウンドの配列をそのままにしておき、必要な際にJSON 関数 を使ってデータを取り出すことをお勧めします。

自動スキーマ検出 の説明にあるとおり、直感的なテーブルスキーマは非構造化MongoDB データへのSQL アクセスを可能にします。JSON 関数 は標準のJSON 関数を使ってMongoDB データをサマライズし、あらゆるネスト構造から値を抽出できます。 カスタムスキーマ定義 では静的なテーブルを定義でき、データのリレーショナルビューでの緻密な制御を可能にします。例えば、parent/child テーブルやfact/dimension テーブルを定義するスキーマを記述することができます。 しかし、これらのスキーマに限定されません。

接続後は、どんなネストされた構造でもデータをフラット化せずにクエリできますFlattenArrays やFlattenObjects でアクセスできるあらゆるリレーションへは、アドホックなSQL クエリを使ってもアクセスが可能です。

次のRestaurant データセットからのサンプルドキュメントを考えてみましょう。

 
{
  "address": {
    "building": "1007",
    "coord": [
      -73.856077,
      40.848447
    ],
    "street": "Morris Park Ave",
    "zipcode": "10462"
  },
  "borough": "Bronx",
  "cuisine": "Bakery",
  "grades": [
    {
      "grade": "A",
      "score": 2,
      "date": {
        "$date": "1393804800000"
      }
    },
    {
      "date": {
        "$date": "1378857600000"
      },
      "grade": "B",
      "score": 6
    },
    {
      "score": 10,
      "date": {
        "$date": "1358985600000"
      },
      "grade": "C"
    }
  ],
  "name": "Morris Park Bake Shop",
  "restaurant_id": "30075445"
} 

SELECT [address.building], [grades.1.grade] FROM restaurants WHERE restaurant_id = '30075445'

ドキュメントの配列を、個別のテーブルのように取得することが可能です。例えば、restaurants コレクションから次のJSON 構造を取得します。

{
  "_id" : ObjectId("568c37b748ddf53c5ed98932"),
  "address" : {
    "building" : "1007",
    "coord" : [-73.856077, 40.848447],
    "street" : "Morris Park Ave",
    "zipcode" : "10462"
  },
  "borough" : "Bronx",
  "cuisine" : "Bakery",
  "grades" : [{
      "date" : ISODate("2014-03-03T00:00:00Z"),
      "grade" : "A",
      "score" : 2
    }, {
      "date" : ISODate("2013-09-11T00:00:00Z"),
      "grade" : "A",
      "score" : 6
    }, {
      "date" : ISODate("2013-01-24T00:00:00Z"),
      "grade" : "A",
      "score" : 10
    }, {
      "date" : ISODate("2011-11-23T00:00:00Z"),
      "grade" : "A",
      "score" : 9
    }, {
      "date" : ISODate("2011-03-10T00:00:00Z"),
      "grade" : "B",
      "score" : 14
    }],
  "name" : "Morris Park Bake Shop",
  "restaurant_id" : "30075445"
}

SELECT * FROM [restaurants.grades]

ベースのrestaurants テーブルからの情報も含めたい場合は、結合を使って実現できます。フラット化された配列はルートドキュメントでのみ結合できます。Sync App では、結合の左部分を、垂直にフラット化したい配列ドキュメントだと判断します。ネストされたMongoDB ドキュメントを結合するには、SupportEnhancedSQL をfalse に設定します。このタイプのクエリはMongoDB API 経由でサポートされています。

SELECT [restaurants].[restaurant_id], [restaurants.grades].* FROM [restaurants.grades] JOIN [restaurants] WHERE [restaurants].name = 'Morris Park Bake Shop'

他の配列の中にある配列を対象としたクエリを作成することも可能です。

以下がInventory コレクションの例です。

{
	"_id": {
		"$oid": "xxxxxxxxxxxxxxxxxxxxxx"
	},
	"Company Branch": "Main Branch",
	"ItemList": [
		{
			"item": "journal",
			"instock": [
				{
					"warehouse": "A",
					"qty": 15
				},
				{
					"warehouse": "B",
					"qty": 45
				}
			]
		},
		{
			"item": "paper",
			"instock": [
				{
					"warehouse": "A",
					"qty": 50
				},
				{
					"warehouse": "B",
					"qty": 5
				}
			]
		}
	]
}

Insert data into the nested arrays using the syntax of <parent array>.<index>.<child array>, as follows:

INSERT INTO [Inventory.ItemList] (p_id, item, [instock.0.warehouse], [instock.0.qty], [instock.0.price]) VALUES ('xxxxxxxxxxxxxxxxxxxxxx', 'NoteBook', 'B', 20, '5$')

The Inventory collection after executing the INSERT statement:

{
	"_id": {
		"$oid": "xxxxxxxxxxxxxxxxxxxxxx"
	},
	"Company Branch": "Main Branch",
	"ItemList": [
		{
			"item": "journal",
			"instock": [
				{
					"warehouse": "A",
					"qty": 15
				},
				{
					"warehouse": "B",
					"qty": 45
				}
			]
		},
		{
			"item": "paper",
			"instock": [
				{
					"warehouse": "A",
					"qty": 50
				},
				{
					"warehouse": "B",
					"qty": 5
				}
			]
		},
		{
			"item": "NoteBook",
			"instock": [
				{
					"warehouse": "B",
					"qty": 20,
					"price": "5$"
				}
			]
		}
	]
}

Sync App では、JSON ストラクチャーをカラム値として返すことができます。Sync App を使って、これらのJSON ストラクチャーにおいて標準SQL 関数を使用できます。このセクションの例では、次の配列を使用します。

[
     { "grade": "A", "score": 2 },
     { "grade": "A", "score": 6 },
     { "grade": "A", "score": 10 },
     { "grade": "A", "score": 9 },
     { "grade": "B", "score": 14 }
]

JSON_EXTRACT

SELECT Name, JSON_EXTRACT(grades,'[0].grade') AS Grade, JSON_EXTRACT(grades,'[0].score') AS Score FROM Students;

JSON_COUNT

SELECT Name, JSON_COUNT(grades,'[x]') AS NumberOfGrades FROM Students;

JSON_SUM

SELECT Name, JSON_SUM(score,'[x].score') AS TotalScore FROM Students;

JSON_MIN

SELECT Name, JSON_MIN(score,'[x].score') AS LowestScore FROM Students;

JSON_MAX

SELECT Name, JSON_MAX(score,'[x].score') AS HighestScore FROM Students;

DOCUMENT

DOCUMENT 関数はすべてのドキュメントをJSON 文字列として取得する場合に用いられます。例として、次のクエリとその結果をご覧ください。

SELECT DOCUMENT(*) FROM Customers;

{ "id": 12, "name": "Lohia Manufacturers Inc.", "address": { "street": "Main Street", "city": "Chapel Hill", "state": "NC"}, "offices": [ "Chapel Hill", "London", "New York" ], "annual_revenue": 35,600,000 }

Sync App は、SQL クエリを対応するMongoDB クエリにマッピングします。ここではトランスフォーメーションの詳細は説明しませんが、いくつか代表的なものを説明します。Sync App は、Aggregation Framework などのMongoDB の機能の良いところを使って望まれる結果を出します。

SELECT クエリ

SELECT * FROM Users

db.users.find()

SELECT user_id, status 
FROM Users

db.users.find(
  {}, 
  { user_id: 1, status: 1, _id: 0 }
)

SELECT * 
FROM Users 
WHERE status = 'A'

db.users.find( 
  { status: "A" }
)

SELECT * 
FROM Users 
WHERE status = 'A' OR age=50

db.users.find(
  { $or: [ { status: "A" }, 
           { age: 50 } ] }
)

SELECT * 
FROM Users 
WHERE name LIKE 'A%'

db.users.find(
  {name: /^a/}
)

SELECT * FROM Users 
WHERE status = 'A'
ORDER BY user_id ASC

db.users.find( { status: "A" }.sort( { user_id: 1 } )

SELECT * 
FROM Users 
WHERE status = 'A' 
ORDER BY user_id DESC

db.users.find( {status: "A" }.sort( {user_id: -1} )

Aggregate クエリ

SELECT Count(*) As Count 
FROM Orders

db.orders.aggregate( [ 
  { 
    $group: { 
      _id: null, 
      count: { $sum: 1 } 
    } 
  } 
] )

SELECT Sum(price) As Total 
FROM Orders

db.orders.aggregate( [ 
  { 
    $group: { 
      _id: null, 
      total: { $sum: "$price" } 
    }
  } 
] )

SELECT cust_id, Sum(price) As total 
FROM Orders 
GROUP BY cust_id 
ORDER BY total

db.orders.aggregate( [ 
  { 
    $group: { 
      _id: "$cust_id", 
      total: { $sum: "$price" } 
    } 
  } ,
  { $sort: {total: 1 } }
] )

SELECT cust_id, ord_date, Sum(price) As total 
FROM Orders 
GROUP BY cust_id, ord_date 
HAVING total > 250

db.orders.aggregate( [ 
  { 
    $group: { 
      _id: { 
        cust_id: "$cust_id", 
        ord_date: { 
          month: { $month: "$ord_date" }, 
          day: { $dayOfMonth: "$ord_date" }, 
          year: { $year: "$ord_date"} 
        } 
      }, 
      total: { $sum: "$price" } 
    }
  }, 
  { $match: { total: { $gt: 250 } } } 
] )

INSERT ステートメント

INSERT INTO users (user_id, age, status, [address.city], [address.postalcode]) 
VALUES ('bcd001', 45, 'A', 'Chapel Hill', 27517)

db.users.insert( 
  { user_id: "bcd001", age: 45, status: "A", address:{ city:"Chapel Hill", postalCode:27514} }
) 

INSERT INTO t1 ("c1") VALUES (('a1', 'a2', 'a3'))

db.users.insert({"c1": ['a1', 'a2', 'a3']})

INSERT INTO t1 ("c1") VALUES (())

db.users.insert({"c1": []})

INSERT INTO t1 ("a.b.c.c1") VALUES (('a1', 'a2', 'a3'))

db.users.insert("a":{"b":{"c":{"c1":['a1','a2', 'a3']}}})

更新ステートメント

UPDATE users 
SET status = 'C', [address.postalcode] = 90210
WHERE age > 25

db.users.update( 
  { age: { $gt: 25 } }, 
  { $set: { status: "C", address.postalCode: 90210 }, 
  { multi: true }
) 

削除ステートメント

DELETE FROM users WHERE status = 'D'

db.users.remove( { status: "D" } )

自動スキーマ検出 で作成されたテーブルスキーマを、スキーマファイルに保存することで拡張できます。スキーマファイルはシンプルな形式で、変更は簡単です。

スキーマファイルの生成

GenerateSchemaFiles を"OnStart" に設定すると、接続時にすべてのテーブルのスキーマを保持します。テーブルスキーマを必要に応じて生成することもできます。GenerateSchemaFiles を"OnUse" に設定して、テーブルにSELECT クエリを実行します。

例えば、レストランのデータセットのスキーマを考えてみましょう。これはMongoDB が提供するサンプルデータです。データセットをダウンロードするには、MongoDB ガイドのはじめにの説明に従います。

コレクションからのサンプルドキュメントは以下のとおりです。

{
  "address":{
    "building":"461",
      "coord":[
        -74.138492,
        40.631136
      ],
      "street":"Port Richmond Ave",
      "zipcode":"10302"
   },
   "borough":"Staten Island",
   "cuisine":"Other",
   "name":"Indian Oven",
   "restaurant_id":"50018994"
}

MongoDB のレストランデータセットのインポート

Mongoimport ユーティリティを使ってデータセットをインポートできます。

mongoimport --db test --collection restaurants --drop --file dataset.json

スキーマのカスタマイズ

GenerateSchemaFiles が設定されている場合、Sync App はLocation プロパティで指定されたフォルダ内にスキーマを格納します。生成されたスキーマでカラムの動作を変更できます。

次のスキーマは、other:bsonpath プロパティを使用して、特定のカラムのデータをコレクションのどこに取得するかを定義します。このモデルを使って、階層構造のアービトラリーレベルをフラット化することができます。

collection 属性は、パースするコレクションを指定します。collection 属性は、同じコレクションに対して複数のスキーマを使う柔軟性を与えます。collection が指定されていない場合は、filename がパースされるコレクションを決定します。

以下は、カラム定義とカラム値を抽出するためのコレクションです。カスタムスキーマ例 では、完全なスキーマを確認できます。

<rsb:script xmlns:rsb="http://www.rssbus.com/ns/rsbscript/2">  

  <rsb:info title="StaticRestaurants" description="Custom Schema for the MongoDB restaurants data set.">  
    <!-- Column definitions -->
    <attr  name="borough"   xs:type="string" other:bsonpath="$.borough"              />
    <attr  name="cuisine"   xs:type="string" other:bsonpath="$.cuisine"              />
    <attr  name="building"  xs:type="string" other:bsonpath="$.address.building"     />
    <attr  name="street"    xs:type="string" other:bsonpath="$.address.street"       />
    <attr  name="latitude"  xs:type="double" other:bsonpath="$.address.coord.0"      />
    <attr  name="longitude" xs:type="double" other:bsonpath="$.address.coord.1"      />
  </rsb:info>  

  <rsb:set attr="collection" value="restaurants"/>

</rsb:script>

このセクションでは、GenerateSchemaFiles によって自動生成された完全なスキーマの例を示します。Location プロパティをスキーマファイルを格納するファイルディレクトリに設定します。スキーマは、以下で構成されています。

• info セクションではMongoDB オブジェクトのリレーショナルビューを可能にします。詳細はカスタムスキーマ定義 を参照してください。

• collection アトリビュートは、パースするコレクションの名前を指定します。collection アトリビュートは、同じコレクションに対して複数のスキーマを定義するために使用できます。collection が指定されていない場合は、filename がパースされるコレクションを決定します。

<rsb:script xmlns:rsb="http://www.rssbus.com/ns/rsbscript/2">  

  <rsb:info title="StaticRestaurants" description="Automatic GenerateSchemaFile">  
    <!-- Column definitions -->
    <attr  name="borough"           xs:type="string"  other:bsonpath="$.borough"          />
    <attr  name="cuisine"           xs:type="string"  other:bsonpath="$.cuisine"          />
    <attr  name="address_building"  xs:type="string"  other:bsonpath="$.address.building" />
    <attr  name="address_street"    xs:type="string"  other:bsonpath="$.address.street"   />
    <attr  name="address_coord_0"   xs:type="double"  other:bsonpath="$.address.coord.0"  />
    <attr  name="address_coord_1"   xs:type="double"  other:bsonpath="$.address.coord.1"  />
  </rsb:info>  

  <rsb:set attr="collection" value="restaurants"/>
</rsb:script>

データ型のマッピング

Sync App は、データソースの型を、スキーマで使用可能な対応するデータ型にマッピングします。以下のテーブルはこれらのマッピングを説明します。

ストアドプロシージャはファンクションライクなインターフェースで、MongoDB の単純なSELECT/INSERT/UPDATE/DELETE 処理にとどまらずSync App の機能を拡張します。

ストアドプロシージャは、パラメータのリストを受け取り、目的の機能を実行し、プロシージャが成功したか失敗したかを示すとともにMongoDB から関連するレスポンスデータを返します。

MongoDB Connector for CData Sync ストアドプロシージャ

JSON ドキュメントを元の構造を保ったまま変更せずにMongoDB コレクションに挿入します。

Input

Result Set Columns

指定されたMongoDB コレクションの構造に基づいてスキーマファイルを生成し、フィールドとデータ型を定義します。

CreateSchema

データモデル内の既存のテーブルまたはビューからローカルスキーマファイル（.rsd）を作成します。

スキーマファイルは、このプロシージャが実行されると、Location 接続プロパティで設定されたディレクトリに作成されます。ファイルを編集してカラムを含めたり除外したり、カラム名を変更したり、カラムのデータ型を変更したりできます。

Sync App はLocation を確認し、.rsd ファイルの名前がデータモデルのテーブルまたはビューに一致するかどうかを判断します。重複がある場合、スキーマファイルはデータモデル内のこのテーブルのデフォルトインスタンスよりも優先されます。既存のテーブルまたはビューに一致しないスキーマファイルがLocation に存在する場合、新しいテーブルまたはビューのエントリがSync App のデータモデルに追加されます。

Input

Result Set Columns

Creates a schema definition for a MongoDB collection, mapping document structure to a tabular format.

Input

Result Set Columns

高度なフィルタリングとプロジェクションを可能にするパススルークエリを実行して、MongoDBコレクションから特定のドキュメントを取得します。

Input

Result Set Columns

ネイティブ構造を維持しながら、MongoDB ドキュメント全体をJSON 形式の文字列として取得します。

Input

Result Set Columns

このセクションでは、MongoDB Sync App の高度な機能を厳選して説明します。

ユーザー定義ビュー

Sync App はユーザー定義ビューの使用をサポートします。これは事前設定されたユーザー定義クエリによって内容が決定される仮想テーブルです。 このビューは、ドライバーに発行されるクエリを直接制御できない場合に有効です。 カスタムビューの作成と設定の概要については、ユーザー定義ビュー を参照してください。

SSL の設定

SSL の設定 を使用して、Sync App が証明書のネゴシエーションをどのように扱うかを調整します。さまざまな証明書形式を選択できます。詳しくは、「接続文字列オプション」にあるSSLServerCert プロパティを参照してください。

ファイアウォールとプロキシ

Windows プロキシを含むファイアウォールとプロキシ に合致するようSync App を設定します。トンネル接続を設定することもできます。

クエリ処理

詳しくは、クエリ処理 を参照してください。

ログ

SSL 設定のカスタマイズ

TLS を有効化するには、UseSSL をTrue に設定します。

この設定により、Sync App はサーバーとのTLS ネゴシエーションを試みます。サーバー証明書は、デフォルトのシステム信頼済み証明書ストアで検証されます。SSLServerCert 接続プロパティを使用して、証明書の検証方法をオーバーライドできます。

別の証明書を指定するには、SSLServerCert 接続プロパティを参照してください。

クライアントSSL 証明書

MongoDB Sync App はクライアント証明書の設定もサポートしています。次を設定すれば、クライアント証明書を使って接続できます。

• SSLClientCert：クライアント証明書のための証明書ストア名。
• SSLClientCertType：TLS / SSL クライアント証明書を格納するキーストアの種類。
• SSLClientCertPassword：TLS / SSL クライアント証明書のパスワード。
• SSLClientCertSubject：TLS / SSL クライアント証明書のサブジェクト。

Firewall またはProxy 経由の接続

次のプロパティを設定します。

• プロキシベースのファイヤーウォールを使用するには、FirewallType、FirewallServer、およびFirewallPort を設定します。
• 接続をトンネルするには、FirewallType をTUNNEL に設定します。
• 認証するには、FirewallUser とFirewallPassword を設定します。
• SOCKS プロキシへの認証には、さらにFirewallType をSOCKS5 に設定します。

Authentication

Kerberos

SSL

SSH

Firewall

Logging

Schema

Miscellaneous

このセクションでは、本プロバイダーの接続文字列で設定可能なAuthentication プロパティの全リストを提供します。

The authentication mechanism that MongoDB will use to authenticate the connection.

解説

Accepted values are MONGODB-CR, SCRAM-SHA-1, SCRAM-SHA-256, GSSAPI, PLAIN, and NONE. The following authentication types correspond to the authentication values.

Authenticating with Challenge-Response

Generally, this property does not need to be set for this authentication type, as the Sync App uses different challenge-response mechanisms by default to authenticate a user to different versions of MongoDB.

• MongoDB 2: MongoDB 2 uses MONGODB-CR to authenticate.
• MongoDB 3.x: MongoDB 3 uses SCRAM-SHA-1 by default; new users you create in MongoDB 3 use this authentication method. However, MongoDB 3 servers will continue to use MONGODB-CR to authenticate users created in MongoDB 2.6.
• MongoDB 4.x: MongoDB 4 uses SCRAM-SHA-1 by default and does not support the deprecated MongoDB MONGODB-CR authentication mechanism.

Authenticating with LDAP

Set AuthScheme to PLAIN to use LDAP authentication. This value specifies the SASL PLAIN mechanism; note that this mechanism transmits credentials over plain-text, so it is not suitable for use without TLS/SSL on untrusted networks.

Authenticating with Kerberos

Set AuthScheme to GSSAPI to use Kerberos authentication. Additionally configure the following properties as configured for the MongoDB environment:

Authenticating with X.509 Authentication

Set AuthScheme to X509 to use X.509 certificate authentication.

MongoDB データベースをホストしているサーバーのホスト名、またはIP アドレス。

解説

MongoDB データベースをホストしているサーバーのホスト名、またはIP アドレス。DNS シードリストを使用して接続する場合は、このオプションを"mongodb+srv://" + MongoDB インスタンスが実行されているサーバーの名前に設定します。

MongoDB Atlas 経由で接続する場合は、Server 接続プロパティをプライマリクラスタのシャード値に設定します（例：cluster0-shard-00-00-test.mongodb.net）。シャーディングについての詳細はこちらを参照してください：MongoDB Sharding

MongoDB データベースのポート。

解説

MongoDB データベースのポート。

認証するユーザーのユーザーID を指定します。

解説

認証サーバーは、ユーザーのID を検証するためにUser とPassword の両方を必要とします。

認証するユーザーのパスワードを指定します。

解説

認証サーバーは、ユーザーのID を検証するためにUser とPassword の両方を必要とします。

MongoDB データベース名。

解説

MongoDB データベース名。

このフィールドはSSL が有効化されているかどうかを設定します。

解説

このフィールドは、Sync App がサーバーとのTLS/SSL 接続をネゴシエートするかどうかを設定します。デフォルトでは、Sync App はサーバーの証明書をシステムの信頼できる証明書ストアと照合します。別の証明書を指定するには、SSLServerCert を設定します。

認証のためのMongoDB データベース名。

解説

認証のためのMongoDB データベース名。データを取得するデータベースと認証データベースが異なる場合のみ必要となります。

このプロパティを使うと、 Server および Port で設定されたサーバーに加え、複数のサーバーを指定できます。サーバー名およびポートの両方を、サーバーをカンマで区切って指定します。

解説

このプロパティを使うと、Server およびPort で設定されたサーバーに加え、レプリカセット内の他のサーバーを指定できます。ReplicaSet、Server、およびPort を使用して、レプリカセット内のすべてのサーバーを指定する必要があります。

サーバー名およびポートの両方をReplicaSet に指定します。サーバーはカンマで区切ります。次に例を示します。

Server=localhost;Port=27017;ReplicaSet=localhost:27018,localhost:27019;

プライマリサーバーを見つけるために、Sync App は、ReplicaSet 内のサーバーとServer およびPort で指定されたサーバーをクエリします。

レプリカセット内のプライマリサーバーだけが書き込み可能です。 セカンダリは、SlaveOK の設定が読み取りを許容している場合に読み取りが可能です。セカンダリにSELECT クエリを実行するストラテジーを設定するには、ReadPreference を参照してください。

Specify the DNS server when resolving MongoDB seed list.

解説

Specify the DNS server when resolving MongoDB seed list.

このセクションでは、本プロバイダーの接続文字列で設定可能なKerberos プロパティの全リストを提供します。

ユーザーの認証に使用されるKerberos キー配布センター（KDC）サービスを識別します。（SPNEGO またはWindows 認証のみ）

解説

Kerberos のプロパティは、SPNEGO またはWindows 認証を使用する場合に使用されます。 Sync App は、Kerberos KDC サービス（通常はドメインコントローラーと同じ場所にあります）にセッションチケットと一時的なセッションキーを要求します。

KerberosKDC が指定されていない場合、Sync App は以下の場所から自動的にプロパティを検出しようとします。

• KRB5 Config File (krb5.ini/krb5.conf)： KRB5_CONFIG 環境変数が設定され、ファイルが存在する場合、Sync App は指定されたファイルからKDC を取得します。見つからない場合は、Sync App はOS に基づいてデフォルトのMIT ロケーションからの読み取りを試みます： C:\ProgramData\MIT\Kerberos5\krb5.ini (Windows) または/etc/krb5.conf (Linux)。
• ドメイン名およびホスト： Kerberos レルムおよびKerberos KDC が別の場所から推測できなかった場合、Sync App は設定されているドメイン名およびホストからそれらを推測します。

ユーザーの認証に使用される Kerberos レルムを識別します。

解説

レルムとは、ドメインに似た論理的なネットワークで、同じマスターKDC の下にあるシステムのグループを定義します。一部のレルムは階層構造を持ち、一方のレルムが他方の上位集合となることもありますが、通常は非階層型（「直接型」）であり、2つのレルム間のマッピングを定義する必要があります。 Kerberos のクロスレルム認証により、異なるレルム間での認証が可能になります。各レルムは、相手レルムのプリンシパル情報を自レルムのKDC に登録しておく必要があります。

Kerberos のプロパティは、SPNEGO またはWindows 認証を使用する場合に使用されます。 Sync App は、Kerberos KDC サービス（通常はドメインコントローラーと同じ場所にあります）にセッションチケットと一時的なセッションキーを要求します。 Kerberos レルムは、管理者が任意の文字列に設定できますが、通常はドメイン名に基づいて設定されます。

Kerberos レルムが指定されていない場合、Sync App は、これらのプロパティを自動的に次の場所から検出しようとします。

• KRB5 Config File (krb5.ini/krb5.conf)： KRB5_CONFIG 環境変数が設定され、ファイルが存在する場合、Sync App は指定されたファイルからデフォルトレルムを取得します。それ以外の場合は、OS に基づいてデフォルトのMIT ロケーションからの読み取りを試みます：C:\ProgramData\MIT\Kerberos5\krb5.ini (Windows) または/etc/krb5.conf (Linux)
• ドメイン名およびホスト： Kerberos レルムおよびKerberos KDC が別の場所から推測できなかった場合、Sync App はユーザー設定されているドメイン名およびホストからそれらを推測します。これは、一部のWindows 環境で機能します。

Kerberos ドメインコントローラーのサービスプリンシパル名（SPN）を指定します。

解説

Kerberos ドメインコントローラー上のSPN が認証先のURL と異なる場合は、このプロパティを使用してSPN をKDC のURL に設定します。

Kerberos ドメインコントローラーのプリンシパル名を確認します。形式はhost/user@realm です。

解説

Kerberos プリンシパルが存在する場合、データベースへの認証には常にそのKerberos プリンシパル名を使用する必要があります。

Kerberos のプリンシパルと暗号化されたキーのペアを含むKeytab ファイルを指定します。

解説

keytab（“key table” の略）は、1つ以上のプリンシパルの長期キーを格納します。 ほとんどの場合、エンドユーザーはクライアントシークレット（パスワード）を使用してKDCに 認証します。 ただし、自動化されたスクリプトやアプリケーションで認証や再認証が行われる場合、keytab を使用する方が効率的です。keytab はパスワードを暗号化された形式で自動的にKDC に送信します。

Keytab は通常、標準形式のファイルで表現され、type:value の形式で命名されます。 通常、type はFILE で、value はファイルの絶対パス名です。 type のもう一つの可能な値はMEMORY で、これは現在のプロセスのメモリに格納された一時的なkeytab を示します。

keytab には1つ以上のエントリが含まれ、各エントリはタイムスタンプ（エントリがkeytab に書き込まれた時刻を示す）、プリンシパル名、キーバージョン番号、暗号化タイプ、および暗号化キー自体で構成されます。 これらはkutil を使用して生成できます。

例：

[admin@myhost]# ktutil

ktutil: addent -password -p starlord/[email protected] -k 1 -e aes256-cts-hmac-sha1-96
Password for starlord/myhost.galaxy.com:

ktutil: addent -password -p starlord/[email protected] -k 1 -e aes128-cts-hmac-sha1-96
Password for starlord/myhost.galaxy.com:

ktutil: addent -password -p starlord/[email protected] -k 1 -e des3-cbc-sha1
Password for starlord/myhost.galaxy.com:

ktutil: wkt /path/to/starlord.keytab

Note： サポートしたいすべての認証方法（暗号化タイプ）に対してプリンシパルを作成する必要があります。

keytab を表示するには、klist -k を使用します。

サービスのKerberos レルムをを指定します。（クロスレルム認証のみ）

解説

KerberosServiceRealm は、クロスレルムKerberos 認証を使用する際にサービスのKerberosRealm を指定するために使われます。

ほとんどの場合、Kerberos 認証の実行には単一のレルムとKDC マシンが使用されるため、このプロパティは必要ありません。ただし、認証チケット（AS リクエスト）とサービスチケット（TGS リクエスト）の取得に異なるレルムとKDC マシンが使用される複雑なセットアップではこのプロパティを使用できます。

サービスのKerberos Key Distribution Center（KDC）を指定します。

解説

KerberosServiceKDC は、クロスレルムKerberos 認証を使用する際にサービスKerberos KDC を指定するために使われます。

ほとんどの場合、Kerberos 認証の実行には単一のレルムとKDC マシンが使用されるため、このプロパティは必要ありません。ただし、認証チケット（AS リクエスト）とサービスチケット（TGS リクエスト）の取得に異なるレルムとKDC マシンが使用される複雑なセットアップではこのプロパティを使用できます。

MIT Kerberos 認証情報キャッシュファイルの完全ファイルパスを指定します。

解説

MIT Kerberos Ticket Manager またはkinit コマンドを使用して作成された認証情報キャッシュファイルを使用する場合は、このプロパティを設定します。

このセクションでは、本プロバイダーの接続文字列で設定可能なSSL プロパティの全リストを提供します。

SSL クライアント認証（2-way SSL）のためのTLS/SSL クライアント証明書ストアを指定します。このプロパティは、他のSSL 関連プロパティと連動して、セキュアな接続を確立します。

解説

このプロパティは、SSL クライアント認証のためのクライアント証明書ストアを指定します。 このプロパティは、証明書ストアの種類を定義するSSLClientCertType、およびパスワードで保護されたストア用のパスワードを指定するSSLClientCertPassword と一緒に使用します。 SSLClientCert が設定され、SSLClientCertSubject が設定されている場合、ドライバーは指定されたサブジェクトに一致する証明書を検索します。

証明書ストアの指定はプラットフォームによって異なります。 Windowsでは、証明書ストアはMY（個人証明書）などの名前で識別されますが、Java では、証明書ストアは通常、証明書とオプションの秘密キーを含むファイルです。

Windows の共通のユーザとシステム証明書ストアの指定は以下のとおりです。

PFXFile タイプの場合、このプロパティをファイル名に設定します。PFXBlob タイプの場合は、このプロパティをPKCS12 形式のファイルのバイナリコンテンツに設定します。

SSL クライアント認証用のTLS/SSL クライアント証明書を格納するキーストアの種類を指定します。プラットフォームや証明書のソースに応じて、さまざまなキーストア形式から選択できます。

解説

このプロパティは、クライアント証明書を指定するために使用されるキーストアの形式と場所を決定します。 サポートされている値には、プラットフォーム固有およびユニバーサルなキーストア形式があります。 有効な値と使用方法は以下のとおりです。

TLS/SSL クライアント証明書ストアにアクセスするために必要なパスワードを指定します。選択した証明書ストアの種類がアクセスにパスワードを必要とする場合、このプロパティを使用します。

解説

このプロパティは、パスワードで保護された証明書ストアを開くために必要なパスワードを指定します。 このプロパティは、PFX やJKS タイプのストアによく推奨されるように、復号化のためにパスワードを必要とする証明書ストアを使用する場合に必要です。

証明書ストアの種類がパスワードを必要としない場合（Windows のUSER やMACHINE など）、このプロパティは空白のままにできます。 認証エラーを回避するため、パスワードが指定された証明書ストアに関連付けられたものと一致していることを確認してください。

TLS/SSL クライアント証明書のサブジェクトを指定し、証明書ストアで場所を検索します。 CN=www.server.com, C=US のように、識別名フィールドのカンマ区切りのリストを使用します。ワイルドカード * は、ストアの先頭の証明書を選択します。

解説

このプロパティは、サブジェクトに基づいてロードするクライアント証明書を決定します。Sync App は、指定されたサブジェクトに完全に一致する証明書を検索します。 完全に一致するものが見つからない場合、Sync App はサブジェクトの値を含む証明書を検索します。 一致する証明書がない場合、証明書は選択されません。

サブジェクトは、識別名フィールドと値のカンマ区切りリストという標準の形式に従うべきです。 例えば、CN=www.server.com, OU=Test, C=US です。一般的なフィールドには以下のものが含まれます。

Note： フィールドにカンマなどの特殊文字が含まれている場合は、値を引用符で囲む必要があります。例：CN="Example, Inc.", C=US。

TLS/SSL を使用して接続する際に、サーバーが受け入れ可能な証明書を指定します。

解説

TLS/SSL 接続を使用している場合は、このプロパティを使用して、サーバーが受け入れるTLS/SSL 証明書を指定できます。このプロパティに値を指定すると、マシンによって信頼されていない他の証明書はすべて拒否されます。

このプロパティは、次のフォームを取ります：

Note：'*' を使用してすべての証明書を受け入れるように指定することも可能ですが、セキュリティ上の懸念があるため推奨されません。

このセクションでは、本プロバイダーの接続文字列で設定可能なSSH プロパティの全リストを提供します。

サービスへのSSH トンネルを確立する際に使用される認証方法。

解説

• None：認証は行われません。現在のSSHUser の値は無視され、接続は匿名でログインされます。
• Password：Sync App は、SSHUser とSSHPassword の値を使用してユーザーを認証します。
• Public_Key：Sync App は、SSHUser とSSHClientCert の値を使用してユーザーを認証します。SSHClientCert には、この認証方法を成功させるために使用可能な秘密鍵が必要です。

SSHUser の認証に使用する証明書。

解説

公開鍵認証を使用するには、SSHClientCert に有効な秘密鍵が含まれている必要があります。 公開鍵はオプションで、含まれていない場合はSync App が秘密鍵から生成します。 Sync App は公開鍵をサーバーに送信し、ユーザーが公開鍵を認証した場合に接続が許可されます。

SSHClientCertType フィールドは、SSHClientCert により指定されたキーストアの種類を指定します。 ストアがパスワードで保護されている場合は、SSHClientCertPassword でパスワードを指定します。

一部の種類のキーストアは、複数のキーを含むことができるコンテナです。 デフォルトでは、Sync App はストアの最初のキーを選択しますが、SSHClientCertSubject を使用して特定のキーを指定することも可能です。

SSHClientCert キーのパスワード（ある場合）。

解説

このプロパティは、証明書ベースの認証を使用する場合のSSH トンネリングに必要です。 SSH 証明書がパスワードで保護されたキーストアにある場合、証明書にアクセスするためにこのプロパティを使用してパスワードを指定します。

SSH クライアント証明書のサブジェクト。

解説

証明書のサブジェクトは、証明書をロードするときにストア内の証明書を検索するために使用されます。

完全に一致するものが見つからない場合、ストアはプロパティの値を含むサブジェクトを検索します。

それでも一致するものが見つからない場合、プロパティは空白で設定され、証明書は選択されません。

"*" に設定すると、証明書ストアの1番目の証明書が選択されます。

証明書のサブジェクトは識別の名前フィールドおよび値のカンマ区切りのリストです。 例えば、"CN=www.server.com, OU=test, C=US, [email protected]"。共通のフィールドとその説明は以下のとおりです。

フィールド値にカンマが含まれている場合は、それを引用符で囲む必要があります。

SSHClientCert 秘密鍵の種類。

解説

このプロパティには次の値の1つを設定できます。

SSH サーバー。

解説

SSH サーバー。

SSH ポート。

解説

SSH ポート。

SSH ユーザー。

解説

SSH ユーザー。

SSH パスワード。

解説

SSH パスワード。

SSH サーバーのフィンガープリント。

解説

SSH サーバーのフィンガープリント。

MongoDB 接続をSSH 経由でトンネリングするかどうか。 SSH を使用します。

解説

デフォルトでは、Sync App はMongoDB に直接接続しようとします。 このオプションを有効にすると、Sync App は代わりにSSHServer とのSSH 接続を確立し、その接続を経由してMongoDB への接続をトンネリングします。

このセクションでは、本プロバイダーの接続文字列で設定可能なFirewall プロパティの全リストを提供します。

provider がプロキシベースのファイアウォールを介してトラフィックをトンネリングするために使用するプロトコルを指定します。

解説

プロキシベースのファイアウォール（またはプロキシファイアウォール）は、ユーザーのリクエストとそれがアクセスするリソースの間に介在するネットワークセキュリティデバイスです。 プロキシは認証済みのユーザーのリクエストを受け取り、ファイアウォールを通過して適切なサーバーにリクエストを送信します。

プロキシは、リクエストを送信したユーザーに代わってデータバケットを評価し転送するため、ユーザーはサーバーに直接接続することなく、プロキシのみに接続します。

次の表は、サポートされている各プロトコルのポート番号情報です。

ファイアウォールを通過し、ユーザーのクエリをネットワークリソースに中継するために使用されるプロキシのIP アドレス、DNS 名、またはホスト名を識別します。

解説

プロキシベースのファイアウォール（またはプロキシファイアウォール）は、ユーザーのリクエストとそれがアクセスするリソースの間に介在するネットワークセキュリティデバイスです。 プロキシは認証済みのユーザーのリクエストを受け取り、ファイアウォールを通過して適切なサーバーにリクエストを送信します。

プロキシは、リクエストを送信したユーザーに代わってデータバケットを評価し転送するため、ユーザーはサーバーに直接接続することなく、プロキシのみに接続します。

プロキシベースのファイアウォールで使用するTCP ポートを指定します。

解説

プロキシベースのファイアウォール（またはプロキシファイアウォール）は、ユーザーのリクエストとそれがアクセスするリソースの間に介在するネットワークセキュリティデバイスです。 プロキシは認証済みのユーザーのリクエストを受け取り、ファイアウォールを通過して適切なサーバーにリクエストを送信します。

プロキシは、リクエストを送信したユーザーに代わってデータバケットを評価し転送するため、ユーザーはサーバーに直接接続することなく、プロキシのみに接続します。

プロキシベースのファイアウォールに認証するアカウントのユーザーID を識別します。

解説

プロキシベースのファイアウォール（またはプロキシファイアウォール）は、ユーザーのリクエストとそれがアクセスするリソースの間に介在するネットワークセキュリティデバイスです。 プロキシは認証済みのユーザーのリクエストを受け取り、ファイアウォールを通過して適切なサーバーにリクエストを送信します。

プロキシは、リクエストを送信したユーザーに代わってデータバケットを評価し転送するため、ユーザーはサーバーに直接接続することなく、プロキシのみに接続します。

プロキシベースのファイアウォールで認証するユーザーアカウントのパスワードを指定します。

解説

プロキシベースのファイアウォール（またはプロキシファイアウォール）は、ユーザーのリクエストとそれがアクセスするリソースの間に介在するネットワークセキュリティデバイスです。 プロキシは認証済みのユーザーのリクエストを受け取り、ファイアウォールを通過して適切なサーバーにリクエストを送信します。

プロキシは、リクエストを送信したユーザーに代わってデータバケットを評価し転送するため、ユーザーはサーバーに直接接続することなく、プロキシのみに接続します。

このセクションでは、本プロバイダーの接続文字列で設定可能なLogging プロパティの全リストを提供します。

ログファイルに含めるコアモジュールを指定します。セミコロンで区切られたモジュール名のリストを使用します。デフォルトでは、すべてのモジュールがログに記録されます。

解説

Sync App は、実行する各操作の詳細を Logfile 接続プロパティで指定されたログファイルに書き込みます。

ログに記録される各操作は、モジュールと呼ばれるカテゴリに分類されます。各モジュールには対応する短いコードがあり、個々の Sync App の操作がどのモジュールに属するかを示すラベルとして使用されます。

この接続プロパティにモジュールコードをセミコロン区切りのリストで設定すると、指定したモジュールに属する操作のみがログファイルに書き込まれます。この設定は今後のログ記録にのみ適用され、既存のログファイルの内容には影響しません。例: INFO;EXEC;SSL;META;

デフォルトでは、すべてのモジュールの操作がログに含まれます。

モジュールを明示的に除外するには、先頭に「-」を付けます。例: -HTTP

サブモジュールにフィルターを適用するには、<モジュール名>.<サブモジュール名> の構文で指定します。たとえば、次の値を設定すると、Sync App は HTTP モジュールに属するアクションのみをログに記録し、さらに HTTP モジュールの Res サブモジュールに属するアクションを除外します: HTTP;-HTTP.Res

Verbosity 接続プロパティによるログファイルのフィルタリングは、この接続プロパティによるフィルタリングよりも優先されます。そのため、Verbosity 接続プロパティで指定したレベルよりも高い詳細レベルの操作は、この接続プロパティで指定したモジュールに属していても、ログファイルには出力されません。

使用可能なモジュールとサブモジュールは次のとおりです。

このセクションでは、本プロバイダーの接続文字列で設定可能なSchema プロパティの全リストを提供します。

テーブル、ビュー、およびストアドプロシージャを定義するスキーマファイルを格納するディレクトリの場所を指定します。サービスの要件に応じて、これは絶対パスまたは相対パスのいずれかで表されます。

解説

Location プロパティは、定義をカスタマイズしたり（例えば、カラム名を変更する、カラムを無視するなど）、新しいテーブル、ビュー、またはストアドプロシージャでデータモデルを拡張する場合にのみ必要です。

指定しない場合、デフォルトの場所は%APPDATA%\\CData\\MongoDB Data Provider\\Schema となり、%APPDATA%はユーザーのコンフィギュレーションディレクトリに設定されます：

レポートされるスキーマを利用可能なすべてのスキーマのサブセットに制限するオプション設定。例えば、 BrowsableSchemas=SchemaA,SchemaB,SchemaC です。

解説

利用可能なデータベーススキーマをすべてリストすると余分な時間がかかり、パフォーマンスが低下します。 接続文字列にスキーマのリストを指定することで、時間を節約しパフォーマンスを向上させることができます。

レポートされるテーブルを利用可能なすべてのテーブルのサブセットに制限するオプション設定。例えば、 Tables=TableA,TableB,TableC です。

解説

データベースによっては、利用可能なすべてのテーブルをリストするのに時間がかかり、パフォーマンスが低下する場合があります。 接続文字列にテーブルのリストを指定することで、時間を節約しパフォーマンスを向上させることができます。

利用可能なテーブルがたくさんあり、すでに作業したいテーブルが決まっている場合、このプロパティを使用して対象のテーブルのみに表示を制限することができます。これを行うには、カンマ区切りのリストで使用したいテーブルを指定します。各テーブルは、角かっこ、二重引用符、またはバッククオートを使用してエスケープされた特殊文字列を含む有効なSQL 識別子である必要があります。 例えば、Tables=TableA,[TableB/WithSlash],WithCatalog.WithSchema.`TableC With Space` です。

Note：複数のスキーマまたはカタログを持つデータソースに接続する場合は、表示する各テーブルを完全修飾名で指定する必要があります。これにより、複数のカタログやスキーマに存在するテーブルが混同されることを防ぎます。

レポートされたビューを使用可能なテーブルのサブセットに制限するオプション設定。例えば、 Views=ViewA,ViewB,ViewC です。

解説

データベースによっては、利用可能なすべてのビューをリストするのに時間がかかり、パフォーマンスが低下する場合があります。 接続文字列にビューのリストを指定することで、時間を節約しパフォーマンスを向上させることができます。

利用可能なビューがたくさんあり、すでに作業したいビューが決まっている場合、このプロパティを使用して対象のビューのみに表示を制限することができます。これを行うには、カンマ区切りのリストで使用したいビューを指定します。各ビューは、角かっこ、二重引用符、またはバッククオートを使用してエスケープされた特殊文字列を含む有効なSQL 識別子である必要があります。 例えば、Views=ViewA,[ViewB/WithSlash],WithCatalog.WithSchema.`ViewC With Space` です。

Note：複数のスキーマまたはカタログを持つデータソースに接続する場合は、確認する各ビューを完全修飾名で指定する必要があります。これにより、複数のカタログやスキーマに存在するビューが混同されることを防ぎます。

このセクションでは、本プロバイダーの接続文字列で設定可能なMiscellaneous プロパティの全リストを提供します。

A comprehensive list detailing the mappings of column names for the built-in fields used in MongoDB.

解説

This property allows users to input a list of MongoDB column names, separated by commas, and maps these built-in columns to newly defined names. If this property is defined, it directs the Sync App to utilize a predefined set of mappings between MongoDB's document fields and the SQL columns.

The remappable built-in columns are "_index", "P_id", "_id" and "parent_id".

For example:

_index=BuiltInIndex,P_id=Root_Id,_id=My_Id,parent_id=My_Parent_id

Remapping these columns is important, particularly in addressing common issues such as "column names must be unique" errors. These conflicts often occur when the Sync App encounters extra columns labeled "_index", "P_id", "_id" or "parent_id" in addition to the standard built-in columns.

This property is useful for modifying reserved names, offering flexibility in database design, and avoiding conflicts.

Specifies the compression method used for network communication between the client and the MongoDB server.

解説

This property enables compression and decompression of messages between the application and MongoDB, thereby reducing the total amount of data transmitted over the network.

• When Compression is set to None, it is not enabled. This means that the data can remain in its original, uncompressed form.
  
• When Compression is set to Snappy, it indicates that network traffic between the MongoDB client and server will be compressed using the Snappy algorithm. Both the client and the server must support Snappy compression, which is enabled by default in most modern versions of the service.
  
• When Compression is set to Zlib, the Sync App activates network compression using the zlib algorithm for communication between the client and server.

This property helps improve performance when working with large MongoDB documents or tables.

By default, the provider will not automatically discover the metadata for a child table as its own distinct table. To enable this functionality, set DataModel to Relational .

解説

When setting DataModel to Relational, the discovery of child tables extends to root-level elements and those found within top-level array elements. Additionally, the provider exposes _id and parent_id columns to enable JOIN operations between parent and child tables. The _id column acts as a primary key for the flattened table, while the parent_id column identifies the parent document.

Determines the format of datetime values returned by the Document function. This property only takes effect when StrictMode=true.

解説

• Canonical: According to MongoDB standards, for dates before the year 1970 or after the year 9999, the format will always be millis.
• ISO8601: The format will always be ISO8601.
• UnixTS: The format will always be millis.

このプロパティは、ネストされた配列のエレメントを個々のカラムにフラット化するかどうかを指定します。デフォルトでは、ネスト配列はJSON 文字列として返されます。このプロパティを、ネスト配列から抽出するエレメントの数に設定します。

解説

デフォルトで、ネスト配列はJSON 文字列として返されます。FlattenArrays プロパティはネスト配列のエレメントをフラット化してそれぞれのカラムとするために使われます。これは短い配列の場合にのみ推奨されます。

ネスト配列から返すエレメントの数にFlattenArrays を設定します。特定されたエレメントはカラムとして返されます。Zero-base のインデックスはカラム名にコンカテネートされます。他のエレメントは無視されます。

例えば、文字列の配列からエレメントのアービトラリー数を返すことができます。

["FLOW-MATIC","LISP","COBOL"]

FlattenArrays を-1 に設定すると、ネストされた配列のすべてのエレメントをフラット化します。

このプロパティは、オブジェクトの属性を個別のカラムにフラット化するかどうかを指定します。

解説

FlattenObjects をtrue に設定すると、オブジェクトのプロパティが個々のカラムにフラット化されます。false に設定すると、ネストされたプロパティはネストされたままでJSON 文字列として返すことができます。
Sync App は、プロパティ名をオブジェクト名とドット区切りで連結してカラム名を生成します。

例えば、次のネストされたオブジェクトを接続時にフラット化できます。

[
     { "grade": "A", "score": 2 },
     { "grade": "A", "score": 6 },
     { "grade": "A", "score": 10 },
     { "grade": "A", "score": 9 },
     { "grade": "B", "score": 14 }
]

スキーマを生成して保存するユーザーの好みのタイミングを示します。

解説

GenerateSchemaFiles を使用すると、自動スキーマ検出 によって識別されたテーブル定義を保存できます。 このプロパティは、Location で指定されたパスの.rsd ファイルにスキーマをアウトプットします。

有効な設定は次のとおりです。

• Never：スキーマファイルは生成されません。
• OnUse：スキーマファイルがまだ存在していない場合に、初めてテーブルが参照されるときにスキーマファイルが生成されます。
• OnStart：現在スキーマファイルを持たないあらゆるテーブルに対して、接続時にスキーマファイルが生成されます。
• OnCreate：CREATE TABLE SQL クエリを実行すると、スキーマファイルが生成されます。

SQL でスキーマを生成する

GenerateSchemaFiles をOnUse に設定すると、Sync App はSELECT クエリを実行したときにスキーマを生成します。スキーマはクエリのそれぞれの参照されたテーブルに対して生成されます。

GenerateSchemaFiles をOnCreate に設定すると、CREATE TABLE クエリが実行されたときにのみスキーマが生成されます。

接続時にスキーマを生成する

このプロパティのもう一つの使い方は、接続するときにデータベース内のすべてのテーブルのスキーマを取得することです。これには、GenerateSchemaFiles をOnStart に設定して接続します。

静的スキーマの別の方法

データ構造が変化する場合には、GenerateSchemaFiles をNever に設定して動的なスキーマを使うことを検討してください。動的なスキーマの詳細については、自動スキーマ検出 を参照してください。

スキーマの編集

スキーマファイルはシンプルな形式となっており、変更は簡単です。詳しくは、カスタムスキーマ定義 を参照してください。

集計やGROUP BY を含まないクエリで返される最大行数を指定します。

解説

このプロパティのデフォルト値である-1 は、クエリに明示的にLIMIT 句が含まれていない限り、行の制限が適用されないことを意味します。 （クエリにLIMIT 句が含まれている場合、クエリで指定された値がMaxRows 設定よりも優先されます。）

MaxRows を0より大きい整数に設定することで、クエリがデフォルトで過度に大きな結果セットを返さないようにします。

このプロパティは、非常に大きなデータセットを返す可能性のあるクエリを実行する際に、パフォーマンスを最適化し、過剰なリソース消費を防ぐのに役立ちます。

サーバーは通常、メモリの過度な使用を防ぐために30分間の非アクティブ状態の後にアイドルカーソルを終了します。このオプションをtrue に設定すると、自動タイムアウトを回避しカーソルをアクティブに保つことができます。

解説

デフォルトでは、MongoDB サーバーはリソースを解放するために、セッションに関連付けられたアイドルカーソルを30分間の非アクティブ状態の後に自動的に閉じます。セッションは、新しいドキュメントのバッチリクエストごとに更新されます。処理に30分以上かかる場合、セッションが期限切れとなり閉じることがあります。 NoCursorTimeout をtrue に設定すると、カーソルが非アクティブ状態によってタイムアウトすることはありません。アプリケーションによって明示的に閉じられるか、カーソルがすべての結果を使い果たすまで開いたままです。

このプロパティは、カーソルが一定期間の非アクティブ状態の後に自動的にタイムアウトするかどうかを制御するのに役立ちます。

特定の問題に対処するため、特殊なシナリオ向けの高度な接続プロパティを指定します。このプロパティは、サポートチームの指示がある場合にのみ使用してください。

解説

このプロパティにより、シニアユーザーはサポートチームのアドバイスに基づいて、特定の状況に対応する隠しプロパティを設定できます。 これらの設定は通常のユースケースには必要ありませんが、特定の要件に対応したり、追加の機能を提供したりすることができます。 複数のプロパティを定義するには、セミコロンで区切られたリストを使用します。

Note：特定のシナリオや問題に対処するためにサポートチームから助言があった場合にのみ、これらのプロパティを設定することを強く推奨します。

統合およびフォーマット

provider がMongoDB にデータをリクエストするときに返す、ページあたりの最大レコード数を指定します。

解説

クエリを処理する際、MongoDB でクエリされたデータすべてを一度にリクエストする代わりに、Sync App はクエリされたデータをページと呼ばれる部分ごとにリクエストすることができます。

この接続プロパティは、Sync App がページごとにリクエストする結果の最大数を決定します。

Note：大きなページサイズを設定すると全体的なクエリ実行時間が短縮される可能性がありますが、その場合、クエリ実行時にSync App がより多くのメモリを使用することになり、タイムアウトが発生するリスクがあります。

テーブルカラムとして公開する擬似カラムを、'TableName=ColumnName;TableName=ColumnName' の形式の文字列で指定します。

解説

このプロパティを使用すると、Sync App がテーブルカラムとして公開する擬似カラムを定義できます。

個々の擬似カラムを指定するには、以下の形式を使用します。

Table1=Column1;Table1=Column2;Table2=Column3

すべてのテーブルのすべての擬似カラムを含めるには、次を使用してください：

*=*

Determines whether queries are sent directly to MongoDB without modification.

解説

When QueryPassthrough is set to true, the specified query can be passed to MongoDB as-is. Currently, only these shell commands are supported:

• db.myCollection.find() returns all fields for all records in the collection.
• db.myCollection.find({ query }) returns all fields for all records in the collection matching the query.
• db.myCollection.find({ query }, { projection }) returns the fields in the projection, for all records matching the query.
• All of the above forms accept a .json() suffix. This returns a single column containing the matching documents as JSON instead of individual fields.

When QueryPassthrough is set to false, the query is not sent directly to MongoDB. Instead, Sync App parses the query and converts it to MongoDB's native query language (MQL).

レプリカセットから読み取るためのストラテジーに設定します。受容される値は、primary、primaryPreferred、secondary、secondaryPreferred、およびnearest です。

解説

このプロパティを使用すると、プライマリメンバー以外のレプリカセット内のメンバにクエリを実行できるようになります。受容される値は次のとおりです。

• primary：すべてのSELECT クエリが、プライマリサーバーに対して実行されます。
• primaryPreferred：プライマリサーバーが利用できない場合、SELECT クエリはセカンダリサーバーに対して実行されます。
• secondary：すべてのSELECT クエリは、セカンダリサーバーに対して実行されます。
• secondaryPreferred：セカンダリサーバーが利用可能な場合、セカンダリサーバーにSELECT クエリが実行されます。そうでない場合は、プライマリサーバーに対して実行されます。
• nearest：SELECT クエリは、レイテンシが最小のサーバーに対して実行されます。

ReadPreference を使用するタイミング

このプロパティを設定すると、書き込み操作がセカンダリマシンにまだレプリケートされていない場合、最新の変更がクエリ結果に反映されないことがあります。 ReadPreference を使用すると、Sync App が古いデータを返すリスクはありますが、次のことを達成できます。

• フェイルオーバークエリの設定：プライマリサーバーが利用できない場合、このプロパティを"primaryPreferred" に設定すると、オンラインでクエリを実行し続けることができます。
• 地理的に分散したレプリカセットに対してより高速にクエリを実行：デプロイメントで複数のデータセンターが使用されている場合、ReadPreference を"nearest" に設定すると、Sync App はレイテンシが最小のレプリカセットメンバーに対してSELECT クエリを実行するためクエリの処理速度が向上します。

Sync App にSELECT ステートメントをセカンダリサーバーに実行させる場合は、SlaveOK も設定する必要があります。そうしないと、Sync App はエラー応答を返します。

This property is used to identify and interact with one or more members of a replica set that are linked to specific tags.

解説

To use the ReadPreferenceTags property, it is necessary to configure the ReadPreference to a value other than the default 'primary' value. The required format consists of a list of semicolon-separated tag sets, where each tag set includes key-value pairs separated by commas.

For example:

• tag1:val1,tag2:val2;: Find members with both tag values. If none are found, find any eligible member.
• tag1:val1;tag2:val2;: Find members with the specified tag1, otherwise find members with the specified tag2. If none are found find any eligible member.
• tag1:val1: Find only members with the specified tag.
• ;: (semicolon only) Find any eligible member. If left empty, any eligible member is targeted.

The maximum number of rows to scan to look for the columns available in a table.

解説

The columns in a table must be determined by scanning table rows. This value determines the maximum number of rows that will be scanned.

Setting a high value may decrease performance. Setting a low value may prevent the data type from being determined properly, especially when there is null data.

Setting this property to a value of -1 causes the Sync App to perform a full scan.

Specifies the type of service the provider can interact with.

解説

The ServiceKind property informs the Sync App of the type of MongoDB service to which it is connecting. This can affect how the connection operates or which features are accessible. Typical values include MongoDB for standard MongoDB deployments. This is the default option.

This property is useful for tools that support various MongoDB services.

セカンダリ（スレーブ）サーバーからデータを読み取るプロバイダーの能力を決定します。プロバイダーがこれらのバックアップシステムにアクセスし、情報を取得できるかどうかを制御します。

解説

SlaveOK プロパティは、レプリカセット内のセカンダリサーバーに対する読み取り操作を許可します。この接続プロパティは非推奨です。推奨オプションは、バージョン4.2以上ではReadPreference です。

true に設定すると、プライマリサーバーに加えてセカンダリレプリカセットサーバーからの読み取りも有効になります。 このプロパティは、ドライバーがReadPreference 設定を使用してセカンダリサーバーにクエリを実行する方法を構成するのに役立ちます。

provider がタイムアウトエラーを返すまでにサーバーからの応答を待機する最大時間を秒単位で指定します。

解説

タイムアウトは、クエリや操作全体ではなくサーバーとの個々の通信に適用されます。 例えば、各ページング呼び出しがタイムアウト制限内に完了する場合、クエリは60秒を超えて実行を続けることができます。

タイムアウトはデフォルトで60秒に設定されています。タイムアウトを無効にするには、このプロパティを0に設定します。

タイムアウトを無効にすると、操作が成功するか、サーバー側のタイムアウト、ネットワークの中断、またはサーバーのリソース制限などの他の条件で失敗するまで無期限に実行されます。

Note： このプロパティは慎重に使用してください。長時間実行される操作がパフォーマンスを低下させたり、応答しなくなる可能性があるためです。

メタデータの検出方法を指定します。

解説

列挙されたオプションの詳細なリストは、プロバイダーがデータを調査するために使用する方法の概要を示します。このプロパティは、各ドキュメントコレクション内の異なるフィールドとそのデータ型を識別するのに役立ちます。

Specifies the strategy that can be used when executing an update statement.

解説

When updating a target document with fields that are replaced or merged, an update statement is executed. If the default value is set to Default, the Sync App replaces the entire original document with a new one. However, if the value is set to Merge, only specific fields in the target document can be updated.

This property helps trigger the system to identify which document needs modifications.

For example, if you have a collection 'classySample' as below.

{
  "_id": "1",
  "message": {
    "component_items": [{"locked": true}],
    "id":1
  }
}

UPDATE [classySample] SET [message.component_items.0.locked] = false  WHERE [message.id] = 1

In the query above, the 'message' document will be replaced with new document constructed with SET clause, the collection after updating looks like

{
  "_id": "1",
  "message": {
    "component_items": [
      {
        "locked": false
      }
    ]
  }
}

But when using Merge, only the 'locked' field in 'component_items' will be updated, the collection becomes

{
    "_id": "1",
    "message": {
        "component_items": [
            {
                "locked": false
            }
        ],
        "id": 1
    }
}

Specifies whether MongoDB queries using the method db.collection.find(), allow retrieval of documents from a specific collection based on defined criteria.

解説

When UseFindAPI is set to true, the Sync App uses the new Find Command API instead of the older OP_QUERY interface. Therefore, this must be set to true in order to query DocumentDB clusters using db.collection.find(). If set to false, the Sync App can revert to the legacy find operation, such as OP_QUERY, particularly when working with older versions of MongoDB servers.

This property is useful for filtering, sorting, and manipulating data in MongoDB's flexible document structure.

カスタムビューを定義するJSON 構成ファイルへのファイルパスを指定します。provider は、このファイルで指定されたビューを自動的に検出して使用します。

解説

UserDefinedViews を使用すると、UserDefinedViews.json というJSON 形式の構成ファイルを通じてカスタムビューを定義および管理できます。 これらのビューはSync App によって自動的に認識され、標準のデータベースビューのようにカスタムSQL クエリを実行できるようになります。 JSON ファイルは、各ビューをルート要素として定義し、その子要素として"query" を持ちます。この"query" にはビューのSQL クエリが含まれています。

次に例を示します。

{
	"MyView": {
		"query": "SELECT * FROM [CData].[Sample].Customers WHERE MyColumn = 'value'"
	},
	"MyView2": {
		"query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
	}
}

このプロパティを使用して、1つのファイルに複数のビューを定義し、ファイルパスを指定できます。 次に例を示します。

UserDefinedViews=C:\Path\To\UserDefinedViews.json

詳しくは、ユーザー定義ビュー を参照してください。

Determines the level of acknowledgment requested for write operations in MongoDB, applicable to standalone mongod, replica sets, or sharded clusters.

解説

The WriteConcern property in MongoDB defines the acknowledgment level required for write operations, determining how confident MongoDB must be about the success of a write before confirming it. The default value is { w: 1 }, meaning the primary node must acknowledge the write operation before returning success to the client.

This property is useful for balancing data safety and performance.

Determines whether write operations can be recorded in the on-disk journal before being acknowledged as successful.

解説

The WriteConcernJournaled property in MongoDB controls whether write operations must be written to the on-disk journal before being acknowledged as successful.

When set to True, MongoDB acknowledges a write operation only after the data has been committed to the on-disk journal. If the option is set to false, a write operation is acknowledged without waiting for journaling.

The WriteConcernTimeout property specifies the maximum time (in milliseconds) that the server should wait for a write concern to be acknowledged before returning an error.

解説

This property specifies the level of acknowledgment requested from MongoDB for write operations, such as INSERT, UPDATE, and DELETE. If a timeout is set for a write operation in MongoDB, it can wait to confirm the write on secondary nodes. If it times out, a write concern error occurs, but the write can still succeed on the primary node.

Sets whether the object type for inserted or updated objects is determined from the existing column metadata or the input value type.

解説

Sets whether the object type for inserted or updated objects is determined from the existing column metadata or the input value type. When the default value Metadata is used, the Sync App uses the data type as determined by the TypeDetectionScheme for objects pushed to MongoDB. When the value is set to RawValue, the type of the object in the INSERT determines what type is used for MongoDB.

For example, if you have a field 'c1' in MongoDB defined as String type, the metadata returns the column as String as well. In the following query, the resulting field in MongoDB is therefore defined as String when using WriteScheme=Metadata. But when using RawValue, the inserting field type is Date instead since the FROM_UNIXTIME() function returns an actual Date object:

INSERT INTO Table1 (c1) VALUES (FROM_UNIXTIME(1636910867039, 0))

Inserting an empty array

INSERT INTO t1 ("c1") VALUES (())

This returns an empty array:

"c1":[]

LZMA from 7Zip LZMA SDK

LZMA SDK is placed in the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or distribute the original LZMA SDK code, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means.

LZMA2 from XZ SDK

Version 1.9 and older are in the public domain.

Xamarin.Forms

Xamarin SDK

The MIT License (MIT)

Copyright (c) .NET Foundation Contributors

All rights reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

NSIS 3.10

Copyright (C) 1999-2025 Contributors THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS COMMON PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.

1. DEFINITIONS

"Contribution" means:

a) in the case of the initial Contributor, the initial code and documentation distributed under this Agreement, and b) in the case of each subsequent Contributor:

i) changes to the Program, and

ii) additions to the Program;

where such changes and/or additions to the Program originate from and are distributed by that particular Contributor. A Contribution 'originates' from a Contributor if it was added to the Program by such Contributor itself or anyone acting on such Contributor's behalf. Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program.

"Contributor" means any person or entity that distributes the Program.

"Licensed Patents " mean patent claims licensable by a Contributor which are necessarily infringed by the use or sale of its Contribution alone or when combined with the Program.

"Program" means the Contributions distributed in accordance with this Agreement.

"Recipient" means anyone who receives the Program under this Agreement, including all Contributors.

2. GRANT OF RIGHTS

a) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form.

b) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Contribution of such Contributor, if any, in source code and object code form. This patent license shall apply to the combination of the Contribution and the Program if, at the time the Contribution is added by the Contributor, such addition of the Contribution causes such combination to be covered by the Licensed Patents. The patent license shall not apply to any other combinations which include the Contribution. No hardware per se is licensed hereunder.

c) Recipient understands that although each Contributor grants the licenses to its Contributions set forth herein, no assurances are provided by any Contributor that the Program does not infringe the patent or other intellectual property rights of any other entity. Each Contributor disclaims any liability to Recipient for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, each Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Program, it is Recipient's responsibility to acquire that license before distributing the Program.

d) Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contribution, if any, to grant the copyright license set forth in this Agreement.

3. REQUIREMENTS

A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that:

a) it complies with the terms and conditions of this Agreement; and

b) its license agreement:

i) effectively disclaims on behalf of all Contributors all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose;

ii) effectively excludes on behalf of all Contributors all liability for damages, including direct, indirect, special, incidental and consequential damages, such as lost profits;

iii) states that any provisions which differ from this Agreement are offered by that Contributor alone and not by any other party; and

iv) states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange.

When the Program is made available in source code form:

a) it must be made available under this Agreement; and

b) a copy of this Agreement must be included with each copy of the Program.

Contributors may not remove or alter any copyright notices contained within the Program.

Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution.

4. COMMERCIAL DISTRIBUTION

Commercial distributors of software may accept certain responsibilities with respect to end users, business partners and the like. While this license is intended to facilitate the commercial use of the Program, the Contributor who includes the Program in a commercial product offering should do so in a manner which does not create potential liability for other Contributors. Therefore, if a Contributor includes the Program in a commercial product offering, such Contributor ("Commercial Contributor") hereby agrees to defend and indemnify every other Contributor ("Indemnified Contributor") against any losses, damages and costs (collectively "Losses") arising from claims, lawsuits and other legal actions brought by a third party against the Indemnified Contributor to the extent caused by the acts or omissions of such Commercial Contributor in connection with its distribution of the Program in a commercial product offering. The obligations in this section do not apply to any claims or Losses relating to any actual or alleged intellectual property infringement. In order to qualify, an Indemnified Contributor must: a) promptly notify the Commercial Contributor in writing of such claim, and b) allow the Commercial Contributor to control, and cooperate with the Commercial Contributor in, the defense and any related settlement negotiations. The Indemnified Contributor may participate in any such claim at its own expense.

For example, a Contributor might include the Program in a commercial product offering, Product X. That Contributor is then a Commercial Contributor. If that Commercial Contributor then makes performance claims, or offers warranties related to Product X, those performance claims and warranties are such Commercial Contributor's responsibility alone. Under this section, the Commercial Contributor would have to defend claims against the other Contributors related to those performance claims and warranties, and if a court requires any other Contributor to pay any damages as a result, the Commercial Contributor must pay those damages.

5. NO WARRANTY

EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely responsible for determining the appropriateness of using and distributing the Program and assumes all risks associated with its exercise of rights under this Agreement, including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and unavailability or interruption of operations.

6. DISCLAIMER OF LIABILITY

EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

7. GENERAL

If any provision of this Agreement is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this Agreement, and without further action by the parties hereto, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.

If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed. In addition, if Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed.

All Recipient's rights under this Agreement shall terminate if it fails to comply with any of the material terms or conditions of this Agreement and does not cure such failure in a reasonable period of time after becoming aware of such noncompliance. If all Recipient's rights under this Agreement terminate, Recipient agrees to cease use and distribution of the Program as soon as reasonably practicable. However, Recipient's obligations under this Agreement and any licenses granted by Recipient relating to the Program shall continue and survive.

Everyone is permitted to copy and distribute copies of this Agreement, but in order to avoid inconsistency the Agreement is copyrighted and may only be modified in the following manner. The Agreement Steward reserves the right to publish new versions (including revisions) of this Agreement from time to time. No one other than the Agreement Steward has the right to modify this Agreement. IBM is the initial Agreement Steward. IBM may assign the responsibility to serve as the Agreement Steward to a suitable separate entity. Each new version of the Agreement will be given a distinguishing version number. The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version. Except as expressly stated in Sections 2(a) and 2(b) above, Recipient receives no rights or licenses to the intellectual property of any Contributor under this Agreement, whether expressly, by implication, estoppel or otherwise. All rights in the Program not expressly granted under this Agreement are reserved.

This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America. No party to this Agreement will bring a legal action under this Agreement more than one year after the cause of action arose. Each party waives its rights to a jury trial in any resulting litigation.