Kladde.Verlauf shows the offices their appointments: the calendar of a month, a single appointment, later an activity feed. The data lives in the container appointments, hierarchically partitioned by /officeId and /month (K3, lesson 3.6.4 and lesson 1.4). This lesson asks how to get it back out: with the point read, with queries, and with pages when a result does not arrive all at once.
Not run against Azure. The code was compiled with Microsoft.Azure.Cosmos 3.64.0 and Newtonsoft.Json 13.0.4; only the part with the stand-in (Exercise 1) was run. Nothing was run against an account or the emulator. What the lesson says about consumption and behavior of the service comes from Microsoft Learn, read on the day of writing.
Point read: the cheapest way
A point read (ReadItemAsync) needs the id and the complete partition key. Learn gives the ranking of the ways to read, from cheapest to most expensive: point read, query with a filter within one partition key, query without an equality or range filter, query with no filter at all. A point read of a 1 KB item costs 1 RU, one of 100 KB about 10 RU; apart from the size (and the double charge for Strong and Bounded Staleness, K3 lesson 3.6.4), nothing affects the cost.
A trap: A query with id and the full key in the WHERE is, according to Learn, not a point read, even if it hits the same item. A design rule follows from this: Give items an id that results without a search (the appointment number), so that you can read instead of query. If the item is missing, the service answers with 404, and the SDK throws a CosmosException:
ItemResponse<Appointment> response = await container.ReadItemAsync<Appointment>(
id, new PartitionKeyBuilder().Add(officeId).Add(month).Build());
Console.WriteLine(response.RequestCharge); // the cost of this read in RU