@azure/cosmos
Version:
Microsoft Azure Cosmos DB Service Node.js SDK for SQL API
97 lines • 5.16 kB
TypeScript
import { SharedOptions } from "./SharedOptions";
/**
* The feed options and query methods.
*/
export interface FeedOptions extends SharedOptions {
/** Opaque token for continuing the enumeration. Default: undefined
* @deprecated Use continuationToken instead.
*/
continuation?: string;
/** Opaque token for continuing the enumeration. Default: undefined */
continuationToken?: string;
/**
* Limits the size of the continuation token in the response. Default: undefined
*
* Continuation Tokens contain optional data that can be removed from the serialization before writing it out to a header.
* By default we are capping this to 1kb to avoid long headers (Node.js has a global header size limit).
* A user may set this field to allow for longer headers, which can help the backend optimize query execution."
*/
continuationTokenLimitInKB?: number;
/**
* Allow scan on the queries which couldn't be served as indexing was opted out on the requested paths. Default: false
*
* In general, it is best to avoid using this setting. Scans are relatively expensive and take a long time to serve.
*/
enableScanInQuery?: boolean;
/**
* The maximum number of concurrent operations that run client side during parallel query execution in the
* Azure Cosmos DB database service. Negative values make the system automatically decides the number of
* concurrent operations to run. Default: 0 (no parallelism)
*/
maxDegreeOfParallelism?: number;
/**
* Max number of items to be returned in the enumeration operation. Default: undefined (server will defined payload)
*
* Expirimenting with this value can usually result in the biggest performance changes to the query.
*
* The smaller the item count, the faster the first result will be delivered (for non-aggregates). For larger amounts,
* it will take longer to serve the request, but you'll usually get better throughput for large queries (i.e. if you need 1000 items
* before you can do any other actions, set `maxItemCount` to 1000. If you can start doing work after the first 100, set `maxItemCount` to 100.)
*/
maxItemCount?: number;
/**
* Note: consider using changeFeed instead.
*
* Indicates a change feed request. Must be set to "Incremental feed", or omitted otherwise. Default: false
*/
useIncrementalFeed?: boolean;
/** Conditions Associated with the request. */
accessCondition?: {
/** Conditional HTTP method header type (IfMatch or IfNoneMatch). */
type: string;
/** Conditional HTTP method header value (the _etag field from the last version you read). */
condition: string;
};
/**
* Enable returning query metrics in response headers. Default: false
*
* Used for debugging slow or expensive queries. Also increases response size and if you're using a low max header size in Node.js,
* you can run into issues faster.
*/
populateQueryMetrics?: boolean;
/**
* Enable buffering additional items during queries. Default: false
*
* This will buffer an additional page at a time (multiplied by maxDegreeOfParallelism) from the server in the background.
* This improves latency by fetching pages before they are needed by the client. If you're draining all of the results from the
* server, like `.fetchAll`, you should usually enable this. If you're only fetching one page at a time via continuation token,
* you should avoid this. If you're draining more than one page, but not the entire result set, it may help improve latency, but
* it will increase the total amount of RU/s use to serve the entire query (as some pages will be fetched more than once).
*/
bufferItems?: boolean;
/**
* This setting forces the query to use a query plan. Default: false
*
* Note: this will disable continuation token support, even for single partition queries.
*
* For queries like aggregates and most cross partition queries, this happens anyway.
* However, since the library doesn't know what type of query it is until we get back the first response,
* some optimization can't happen until later.
*
* If this setting is enabled, it will force query plan for the query, which will save some network requests
* and ensure parallelism can happen. Useful for when you know you're doing cross-partition or aggregate queries.
*/
forceQueryPlan?: boolean;
/** Limits the query to a specific partition key. Default: undefined
*
* Scoping a query to a single partition can be accomplished two ways:
*
* `container.items.query('SELECT * from c', { partitionKey: "foo" }).toArray()`
* `container.items.query('SELECT * from c WHERE c.yourPartitionKey = "foo"').toArray()`
*
* The former is useful when the query body is out of your control
* but you still want to restrict it to a single partition. Example: an end user specified query.
*/
partitionKey?: any;
}
//# sourceMappingURL=FeedOptions.d.ts.map