What's changed: Created DP-420 Chapter 2 (Domain 1 second-half: SDK client connectivity (gateway vs direct/singleton/emulator/preferred regions/429-transient retries); SQL queries and data access (arrays-nesting-aggregation-subqueries-functions/point op vs query/patch/Transactional Batch/Bulk/ETag optimistic concurrency/consistency override-session token/pagination-continuation token/query metrics); server-side JS (stored procedure = ACID in one logical partition/pre-post triggers/UDF)).
2.2SQL queries and data access
Understand Cosmos DB for NoSQL SQL queries (arrays/nesting/aggregation/subqueries/functions), point ops vs queries, patch, Transactional Batch, Bulk, optimistic concurrency with ETag, consistency override, pagination/continuation tokens, 429 handling, and query metrics.
Data access has point operations (fetch one by id + partition key) and query operations (fetch many by criteria); their RU cost and proper use matter.
2.2.1Point ops, queries, and patch
Point operations (read/create/replace/upsert/delete by id + partition key) are cheapest and fastest—always use them when you know a single item. Query operations use SQL (arrays/nested objects/aggregation/ordering/correlated subqueries/type-check, math, string, date functions) for many items, but RU grows with the query. To update only part of an item, use a patch operation (partial update) to avoid full replacement and improve efficiency.
2.2.2Transactional Batch, Bulk, ETag, continuation tokens
Transactional Batch processes multiple items within one logical partition atomically (all-or-nothing). Bulk Support ingests many items in parallel at high throughput (not atomic; for bulk loading). Optimistic concurrency with ETag and If-Match updates only when the ETag matches the read-time value, preventing conflicting overwrites (mismatch → 412). Consistency can be overridden via query request options (only toward weaker, not stronger), and session tokens carry session consistency. Fetch large results with pagination + continuation tokens. Use query metrics to diagnose RU and execution breakdown.
Cues: "single item by id + partition key" = point op (cheapest). "atomic multiple in one logical partition" = Transactional Batch. "fast bulk ingest (non-atomic)" = Bulk. "prevent conflicting overwrite" = ETag/If-Match (mismatch 412). "next page" = continuation token. "partial update" = patch.
Watch the mix-ups: (1) Transactional Batch (atomic, one logical partition) vs Bulk (high throughput, non-atomic). (2) Making a query cross-partition raises RU. (3) ETag mismatch is 412—re-read and retry. (4) Consistency can be overridden only toward weaker, not stronger.
2.2.3Section summary
- Single item = point op (cheapest); many by criteria = query; partial = patch
- Transactional Batch = atomic in one logical partition; Bulk = non-atomic fast bulk ingest
- ETag/If-Match for optimistic concurrency (mismatch 412); continuation tokens for pagination
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to fetch a single item whose id and partition key are known at the lowest RU. Best?
Q2. You want to update multiple items in one logical partition atomically (all-or-nothing). Best?
Q3. You want to ingest millions of items at high throughput (atomicity not needed). Best?
Q4. With concurrent updates, you want to write only if unchanged since read, preventing conflicting overwrites. Best?
Q5. You want to page a large query result and efficiently fetch the next page. Best?