A tramway-maintenance log stores large Cosmos items. Operators must update only the lastInspected field without rewriting the entire document and risking clobbered concurrent edits. Which SDK approach fits best?
Select an answer to reveal the explanation.
Short Explanation
Don’t rewrite the whole novel to change one date stamp. Patch the lastInspected path and leave the rest of the tram log alone.
Full Explanation
For large tramway-maintenance log items where operators must update only lastInspected, Cosmos DB patch operations change specific paths without replacing the entire document. That reduces bandwidth, lowers RU cost relative to full replaces on large items, and avoids clobbering unrelated fields that concurrent editors may have changed—exactly the risk called out in the scenario.
Always replacing the entire item with a partially filled object can clear unspecified properties and overwrite concurrent edits, defeating the goal of a surgical field update. Deleting and recreating the item on every inspection checkbox is disruptive, breaks references/ETags naively, and is unnecessary for a single field change. Storing the inspection date only in Application Insights custom events moves the system of record into telemetry, which is not durable business state for maintenance logs in Cosmos.
Exam caveat: patch still requires concurrency controls (ETag/If-Match) when concurrent updates matter; patch alone does not eliminate lost updates if two patches race without conditions. Not all older SDK versions expose the same patch surface—use a supported SDK. Operational check: patch lastInspected on a large document, point-read afterward to confirm other fields remain unchanged, and optionally send If-Match with the prior ETag to verify precondition failure when a concurrent replace occurred.