Cloudant Version Support

The connector leverages the Cloudant API to enable bidirectional access to Cloudant data through standard SQL. See Query Mapping for SQL-to-Cloudant-query mappings and more information about accessing unstructured data in Cloudant through SQL.

Authenticating to Cloudant

There are two authentication methods available for connecting to Cloudant: IBM Cloudant Legacy and IBM Cloud IAM.

Authenticating with IBM Cloudant Legacy

Set the User and Password to your service credentials.

To create an IBM Cloudant service credential:

1. In the IBM Cloud dashboard, go to the Menu icon > Resource List, and open your IBM Cloudant service instance.
2. In the menu, click Service credentials.
3. Click the New credential button and enter a name for the new credential in the Add new credential window.
4. Click the Add button. Your credentials are added to the Service credentials table.
5. Click View credentials under Actions and extract the User and Password from the json file.

Authenticating to Local Instance

We support Local instances from version 1.1.0 and above.

To authenticate to your local instance you need to set:

1. URL to the Url of your local instance. For example: http://localhost:8006
2. User to your Username.
3. Password to your Password.

Fine-Tuning Data Access

You can use the following properties to gain control over column behavior in Automatic Schema Discovery.

• RowScanDepth: This property determines the number of rows that will be scanned to detect column data types when generating table metadata.
• TypeDetectionScheme: This property allows more control over the strategy implemented by the RowScanDepth property.

Cloudant is a schemaless document database that provides high performance, availability, and scalability. These features are not necessarily incompatible with a standards-compliant query language like SQL-92. The following sections show various schemes that the connector offers to bridge the gap with relational SQL and a document database.

The connector models the schemaless Cloudant objects into relational tables and translates SQL queries into Cloudant queries to get the requested data. See Query Mapping for more details on how various Cloudant operations are represented as SQL.

The Automatic Schema Discovery scheme automatically finds the data types in a Cloudant object by scanning a configured number of rows of the object. You can use RowScanDepth, FlattenArrays, and FlattenObjects to control the relational representation of the collections in Cloudant.

The schema of the table is necessary to report metadata, but you can write Free-Form Queries not tied to the schema to select, insert, update, or delete data from columns that do not exist in the schema.

The connector automatically infers a relational schema by inspecting a series of Cloudant documents in a collection. You can use the RowScanDepth property to define the number of documents the connector will scan to do so. The columns identified during the discovery process depend on the FlattenArrays and FlattenObjects properties.

Flattening Objects

If FlattenObjects is set, all nested objects will be flattened into a series of columns. For example, consider the following document:

{
  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
}

If FlattenObjects is not set, then the address.street, address.city, and address.state columns will not be broken apart. The address column of type string will instead represent the entire object. Its value would be {street: "Main Street", city: "Chapel Hill", state: "NC"}. See JSON Functions for more details on working with JSON aggregates.

You can change the separator character in the column name from a dot by setting SeparatorCharacter.

Flattening Arrays

The FlattenArrays property can be used to flatten array values into columns of their own. This is only recommended for arrays that are expected to be short, for example the coordinates below:

"coord": [ -73.856077, 40.848447 ]

As discussed in Automatic Schema Discovery, intuited table schemas enable SQL access to unstructured Cloudant data. JSON Functions enable you to use standard JSON functions to summarize Cloudant data and extract values from any nested structures. However, you are not limited to these schemes.

After connecting you can query any nested structure without flattening the data. Any relations that you can access with FlattenArrays and FlattenObjects can also be accessed with an ad hoc SQL query.

{
  "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'

It is possible to retrieve an array of documents as if it were a separate table. Take the following JSON structure from the restaurants collection for example:

{
  "_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]

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

The connector can return JSON structures as column values. The connector enables you to use standard SQL functions to work with these JSON structures. The examples in this section use the following array:

[
     { "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

The DOCUMENT function can be used to retrieve the entire document as a JSON string. See the following query and its result as an example:

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 }

The connector maps SQL queries into the corresponding Cloudant queries. The connector uses the Selector syntax to compute the desired results.

A detailed description of all the transformations is out of scope, but we will describe some of the common elements that are used.

SELECT Queries

The SELECT statement is mapped to the GET and POST methods. Below are example queries and the corresponding request payloads.

SELECT *
FROM sales

SELECT _id, value
FROM sales

{
"fields": [
"_id",
"value"
],
"skip": 0,
"selector": {
"_id": {
"$exists": true
}
}
}

SELECT *
FROM sales
WHERE value=175033291697

{
"selector": {
"value": {
"$eq": 175033291697
}
},
"skip": 0
}

SELECT *
FROM sales
WHERE value = 175033291697 OR month='June'

{
"selector": {
"$or": [
{
"value": {
"$eq": 175033291697
}
},
{
"month": {
"$eq": "June"
}
}
]
},
"skip": 0
}

SELECT *
FROM sales
WHERE name LIKE 'A%'

{
"selector": {
"name": {
"$regex": "A%"
}
},
"skip": 0
}

SELECT * FROM sales
WHERE month='June'
ORDER BY _id ASC

{
"skip": 0,
"sort": [
{
"_id": "asc"
}
],
"selector": {
"month": {
"$eq": "June"
}
}
}

SELECT *
FROM sales
WHERE month='June'
ORDER BY _id DESC

{
"skip": 0,
"sort": [
{
"_id": "desc"
}
],
"selector": {
"month": {
"$eq": "June"
}
}

}

INSERT Statements

The INSERT statement is mapped to the HTTP POST request, as shown in the following query and request payload.

SQL Query

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

Cloudant Query

{
  "address": {
    "city": "Chapel Hill",
    "postalcode": 27517
  },
  "_id": "bcd001",
  "age": 45,
  "status": "A"
}

UPDATE Statements

The UPDATE statement is mapped to the HTTP PUT method, as shown in the following query and request payload.

SQL Query

UPDATE users 
SET status = 'C', [address.postalcode] = 90210
WHERE _id = 'bcd001'

Cloudant Query

{
  "_id": "bcd001",
  "_rev": "1-446f6c67e3a483feae8eaf112f18892c",
  "status": "C",
  "age": 45,
  "address": {
    "city": "Chapel Hill",
    "postalcode": 90210
  }
}

DELETE Statements

The DELETE statement is mapped to the DELETE method as shown below.

SQL Query

DELETE FROM users WHERE _id = 'bcd001'

Cloudant Query

You can query the system tables described in this section to access schema information, information on data source functionality, and batch operation statistics.

Schema Tables

The following tables return database metadata for Cloudant:

• sys_catalogs: Lists the available databases.
• sys_schemas: Lists the available schemas.
• sys_tables: Lists the available tables and views.
• sys_tablecolumns: Describes the columns of the available tables and views.
• sys_procedures: Describes the available stored procedures.
• sys_procedureparameters: Describes stored procedure* parameters.
• sys_keycolumns: Describes the primary and foreign keys.
• sys_indexes: Describes the available indexes.

Data Source Tables

The following tables return information about how to connect to and query the data source:

• sys_connection_props: Returns information on the available connection properties.
• sys_sqlinfo: Describes the SELECT queries that the connector can offload to the data source.

Query Information Tables

The following table returns query statistics for data modification queries:

• sys_identity: Returns information about batch operations or single updates.

Lists the available databases.

The following query retrieves all databases determined by the connection string:

SELECT * FROM sys_catalogs

Columns

Lists the available schemas.

The following query retrieves all available schemas:

SELECT * FROM sys_schemas

Columns

Lists the available tables.

The following query retrieves the available tables and views:

SELECT * FROM sys_tables

Columns

Describes the columns of the available tables and views.

The following query returns the columns and data types for the Movies table:

SELECT ColumnName, DataTypeName FROM sys_tablecolumns WHERE TableName='Movies' 

Columns

Lists the available stored procedures.

The following query retrieves the available stored procedures:

SELECT * FROM sys_procedures

Columns

Describes stored procedure* parameters.

The following query returns information about all of the input parameters for the SelectEntries stored procedure:

SELECT * FROM sys_procedureparameters WHERE ProcedureName='SelectEntries' AND Direction=1 OR Direction=2

Columns

Describes the primary and foreign keys. The following query retrieves the primary key for the Movies table:

SELECT * FROM sys_keycolumns WHERE IsKey='True' AND TableName='Movies' 

Columns

Describes the foreign keys. The following query retrieves all foreign keys which refer to other tables:

SELECT * FROM sys_foreignkeys WHERE ForeignKeyType = 'FOREIGNKEY_TYPE_IMPORT'

Columns

Describes the available indexes. By filtering on indexes, you can write more selective queries with faster query response times.

The following query retrieves all indexes that are not primary keys:

SELECT * FROM sys_indexes WHERE IsPrimary='false'

Columns

Returns information on the available connection properties and those set in the connection string.

When querying this table, the config connection string should be used:

jdbc:cdata:cloudant:config:

The following query retrieves all connection properties that have been set in the connection string or set through a default value:

SELECT * FROM sys_connection_props WHERE Value <> ''

Columns

Describes the SELECT query processing that the connector can offload to the data source.

Collaborative Query Processing

When working with data sources that do not support SQL-92, you can query the sys_sqlinfo view to determine the query capabilities of the underlying APIs, expressed in SQL syntax. The connector offloads as much of the SELECT statement processing as possible to the server and then processes the rest of the query in memory.

Discovering the Data Source's SELECT Capabilities

Below is an example data set of SQL capabilities. The following result set indicates the SELECT functionality that the connector can offload to the data source or process client side. Your data source may support additional SQL syntax. Some aspects of SELECT functionality are returned in a comma-separated list if supported; otherwise, the column contains NO.

SELECT * FROM sys_sqlinfo WHERE Name='SUPPORTED_OPERATORS'

Columns

Returns information about attempted modifications.

The following query retrieves the Ids of the modified rows in a batch operation:

SELECT * FROM sys_identity

Columns

Stored procedures* are available to complement the data available from the NoSQL Database. It may be necessary to update data available from a view using a stored procedure* because the data does not provide for direct, table-like, two-way updates. In these situations, the retrieval of the data is done using the appropriate view or table, while the update is done by calling a stored procedure. Stored procedures* take a list of parameters and return back a dataset that contains the collection of tuples that constitute the response.

Jitterbit Connector for Cloudant Stored Procedures

Creates a schema definition of a table in Cloudant. Control column discovery with FlattenObjects, FlattenArrays, TypeDetectionScheme, and RowScanDepth.

Input

Result Set Columns

Gets an authentication token from IBM Cloud. The connection property ApiKey must be specified when calling this stored procedure.

Result Set Columns

Refreshes the OAuth access token used for authentication with IBM Cloud. The connection property ApiKey must be specified when calling this stored procedure.

Input

Result Set Columns

This section details a selection of advanced features of the Cloudant connector.

User Defined Views

The connector allows you to define virtual tables, called user defined views, whose contents are decided by a pre-configured query. These views are useful when you cannot directly control queries being issued to the drivers. See User Defined Views for an overview of creating and configuring custom views.

SSL Configuration

Use SSL Configuration to adjust how connector handles TLS/SSL certificate negotiations. You can choose from various certificate formats; see the SSLServerCert property under "Connection String Options" for more information.

Proxy

To configure the connector using Private Agent proxy settings, select the Use Proxy Settings checkbox on the connection configuration screen.

The Jitterbit Connector for Cloudant allows you to define a virtual table whose contents are decided by a pre-configured query. These are called User Defined Views, which are useful in situations where you cannot directly control the query being issued to the driver, e.g. when using the driver from Jitterbit. The User Defined Views can be used to define predicates that are always applied. If you specify additional predicates in the query to the view, they are combined with the query already defined as part of the view.

• Create a JSON-formatted configuration file defining the views you want.
• DDL statements.

Defining Views Using a Configuration File

User Defined Views are defined in a JSON-formatted configuration file called UserDefinedViews.json. The connector automatically detects the views specified in this file.

You can also have multiple view definitions and control them using the UserDefinedViews connection property. When you use this property, only the specified views are seen by the connector.

• Each root element defines the name of a view.
• Each root element contains a child element, called query, which contains the custom SQL query for the view.

For example:

{
	"MyView": {
		"query": "SELECT * FROM Movies WHERE MyColumn = 'value'"
	},
	"MyView2": {
		"query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
	}
}

"UserDefinedViews", "C:\Users\yourusername\Desktop\tmp\UserDefinedViews.json"

Schema for User Defined Views

Working with User Defined Views

SELECT * FROM Customers WHERE City = 'Raleigh';

SELECT * FROM UserViews.RCustomers WHERE Status = 'Active';

SELECT * FROM Customers WHERE City = 'Raleigh' AND Status = 'Active';

Customizing the SSL Configuration

By default, the connector attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store.

To specify another certificate, see the SSLServerCert property for the available formats to do so.

The advanced configurations properties are the various options that can be used to establish a connection. This section provides a complete list of the options you can configure. Click the links for further details.

Authentication

OAuth

SSL

Schema

Miscellaneous

This section provides a complete list of authentication properties you can configure.

The type of authentication to use when connecting to Cloudant.

Possible Values

Data Type

string

Default Value

"Auto"

Remarks

• Auto: Lets the driver decide automatically based on the other connection properties you have set.
• Basic: Set this to use BASIC user / password authentication.
• OAuth: Set this to perform OAuth authentication. For this method you will need the APIKey and URL of Cloudant instance.

The URL used to connect to the Cloudant.

Data Type

string

Default Value

""

Remarks

The HTTP or HTTPS URL used to connect to the Cloudant in the format https://{instance id}-bluemix.cloudantnosqldb.appdomain.cloud or in case of self hosting server http[s]://{server}:{port}

The Cloudant user account used to authenticate.

Data Type

string

Default Value

""

Remarks

Together with Password, this field is used to authenticate against the Cloudant server.

The password used to authenticate the user.

Data Type

string

Default Value

""

Remarks

The User and Password are together used to authenticate with the server.

The API Key used to identify the user to IBM Cloud.

Data Type

string

Default Value

""

Remarks

Access to resources in the Cloudant REST API is governed by an API key in order to retrieve token. An API Key created by navigating to Manage --> Access (IAM) --> Users and clicking 'Create'.

This section provides a complete list of OAuth properties you can configure.

Set this property to initiate the process to obtain or refresh the OAuth access token when you connect.

Possible Values

Data Type

string

Default Value

"OFF"

Remarks

The following options are available:

1. OFF: Indicates that the OAuth flow will be handled entirely by the user. An OAuthAccessToken will be required to authenticate.
2. GETANDREFRESH: Indicates that the entire OAuth Flow will be handled by the connector. If no token currently exists, it will be obtained by prompting the user via the browser. If a token exists, it will be refreshed when applicable.
3. REFRESH: Indicates that the connector will only handle refreshing the OAuthAccessToken. The user will never be prompted by the connector to authenticate via the browser. The user must handle obtaining the OAuthAccessToken and OAuthRefreshToken initially.

The OAuth refresh token for the corresponding OAuth access token.

Data Type

string

Default Value

""

Remarks

The OAuthRefreshToken property is used to refresh the OAuthAccessToken when using OAuth authentication.

The lifetime in seconds of the OAuth AccessToken.

Data Type

string

Default Value

""

Remarks

Pair with OAuthTokenTimestamp to determine when the AccessToken will expire.

The Unix epoch timestamp in milliseconds when the current Access Token was created.

Data Type

string

Default Value

""

Remarks

Pair with OAuthExpiresIn to determine when the AccessToken will expire.

This section provides a complete list of SSL properties you can configure.

The certificate to be accepted from the server when connecting using TLS/SSL.

Data Type

string

Default Value

""

Remarks

If using a TLS/SSL connection, this property can be used to specify the TLS/SSL certificate to be accepted from the server. Any other certificate that is not trusted by the machine is rejected.

This property can take the following forms:

If not specified, any certificate trusted by the machine is accepted.

Certificates are validated as trusted by the machine based on the System's trust store. The trust store used is the 'javax.net.ssl.trustStore' value specified for the system. If no value is specified for this property, Java's default trust store is used (for example, JAVA_HOME\lib\security\cacerts).

Use '*' to signify to accept all certificates. Note that this is not recommended due to security concerns.

This section provides a complete list of schema properties you can configure.

A path to the directory that contains the schema files defining tables, views, and stored procedures.

Data Type

string

Default Value

"%APPDATA%\\Cloudant Data Provider\Schema"

Remarks

The path to a directory which contains the schema files for the connector (.rsd files for tables and views, .rsb files for stored procedures). The folder location can be a relative path from the location of the executable. The Location property is only needed if you want to customize definitions (for example, change a column name, ignore a column, and so on) or extend the data model with new tables, views, or stored procedures.

If left unspecified, the default location is "%APPDATA%\\Cloudant Data Provider\Schema" with %APPDATA% being set to the user's configuration directory:

This property restricts the schemas reported to a subset of the available schemas. For example, BrowsableSchemas=SchemaA,SchemaB,SchemaC.

Data Type

string

Default Value

""

Remarks

Listing the schemas from databases can be expensive. Providing a list of schemas in the connection string improves the performance.

This property restricts the tables reported to a subset of the available tables. For example, Tables=TableA,TableB,TableC.

Data Type

string

Default Value

""

Remarks

Listing the tables from some databases can be expensive. Providing a list of tables in the connection string improves the performance of the connector.

This property can also be used as an alternative to automatically listing views if you already know which ones you want to work with and there would otherwise be too many to work with.

Note that when connecting to a data source with multiple schemas or catalogs, you will need to provide the fully qualified name of the table in this property, as in the last example here, to avoid ambiguity between tables that exist in multiple catalogs or schemas.

Restricts the views reported to a subset of the available tables. For example, Views=ViewA,ViewB,ViewC.

Data Type

string

Default Value

""

Remarks

Listing the views from some databases can be expensive. Providing a list of views in the connection string improves the performance of the connector.

This property can also be used as an alternative to automatically listing views if you already know which ones you want to work with and there would otherwise be too many to work with.

Specify the views you want in a comma-separated list. Each view should be a valid SQL identifier with any special characters escaped using square brackets, double-quotes or backticks. For example, Views=ViewA,[ViewB/WithSlash],WithCatalog.WithSchema.`ViewC With Space`.

Note that when connecting to a data source with multiple schemas or catalogs, you will need to provide the fully qualified name of the table in this property, as in the last example here, to avoid ambiguity between tables that exist in multiple catalogs or schemas.

Whether to list views from Cloudant or not.

Data Type

bool

Default Value

false

Remarks

Set this property to true for Cloudant views to show up when listing tables.

This section provides a complete list of miscellaneous properties you can configure.

Set FlattenArrays to the number of array elements to flatten into columns. Otherwise, arrays are returned as JSON strings.

Data Type

string

Default Value

""

Remarks

By default, nested arrays are returned as strings of JSON. The FlattenArrays property can be used to flatten the elements of nested arrays into columns of their own: Set FlattenArrays to the number of elements you want to return from nested arrays. The zero-based index is concatenated to the column name with a dot or the character specified by SeparatorCharacter. Other elements are ignored.

For example, you can return an arbitrary number of elements from an array of strings:

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

Setting FlattenArrays to -1 will flatten all the elements of nested arrays.

Set FlattenObjects to true to flatten object properties into columns of their own. Otherwise, embedded objects as raw JSON strings.

Data Type

bool

Default Value

true

Remarks

Set FlattenObjects to true to flatten object properties into columns of their own. Otherwise, embedded objects as raw JSON strings. The property name is concatenated onto the object name with a dot or the character specified by SeparatorCharacter.

For example, you can flatten the nested objects below at connection time:

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

Set FlexibleSchema to true to scan for additional metadata on the query result set. Otherwise, the metadata will remain the same.

Data Type

bool

Default Value

true

Remarks

Set FlexibleSchema to true to scan for additional metadata on the query result set. Otherwise, the metadata will remain the same.

Limits the number of rows returned rows when no aggregation or group by is used in the query. This helps avoid performance issues at design time.

Data Type

int

Default Value

-1

Remarks

Limits the number of rows returned rows when no aggregation or group by is used in the query. This helps avoid performance issues at design time.

These hidden properties are used only in specific use cases.

Data Type

string

Default Value

""

Remarks

The properties listed below are available for specific use cases. Normal driver use cases and functionality should not require these properties.

Specify multiple properties in a semicolon-separated list.

Integration and Formatting

The maximum number of results to return per page from Cloudant.

Data Type

int

Default Value

1000

Remarks

The Pagesize property affects the maximum number of results to return per page from Cloudant. Setting a higher value may result in better performance at the cost of additional memory allocated per page consumed.

This property indicates whether or not to include pseudo columns as columns to the table.

Data Type

string

Default Value

""

Remarks

This setting is particularly helpful in Entity Framework, which does not allow you to set a value for a pseudo column unless it is a table column. The value of this connection setting is of the format "Table1=Column1, Table1=Column2, Table2=Column3". You can use the "*" character to include all tables and all columns; for example, "*=*".

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

Data Type

int

Default Value

50

Remarks

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

The character or characters used to denote hierarchy.

Data Type

string

Default Value

"."

Remarks

In order to flatten out hierarchical structures, the connector needs some specifier that states the path to a column through the hierarchy. If this value is "." and a column comes back with the name address.city, this indicates that there is a mapped attribute with a child called city. If your data has columns that already use a single period within the attribute name, set the SeparatorCharacter to a different character or characters.

The value in seconds until the timeout error is thrown, canceling the operation.

Data Type

int

Default Value

60

Remarks

If Timeout = 0, operations do not time out. The operations run until they complete successfully or until they encounter an error condition.

If Timeout expires and the operation is not yet complete, the connector throws an exception.

Option for how the provider will scan the data to determine the fields and data types in each document collection.

Data Type

string

Default Value

"RowScan"

Remarks

Since Cloudant is schemaless, the columns in a table must be determined by scanning table rows. Set TypeDetectionScheme to toggle the automatic discovery of data types. Set RowScanDepth to configure type detection.

See Also

Type detection is part of Automatic Schema Discovery. Set FlattenArrays and FlattenObjects to configure how the connector projects columns over the hierarchical data.

You can fine-tune the discovered columns and data types by calling CreateSchema to generate a schema file. Schema files have a simple format that makes it easy to change column behavior.