Playground Checkpoint
Design and build a real schema — no auto-grading, just a real attempt.
The Challenge
Six chapters of real Cassandra, all converging on one real challenge: design GreenMart's actual fleet-tracking keyspace, the way this whole Act argued it should be designed — starting from the real question the truck asks, not from a list of entities.
Open the Playground and build it for real: create a table with a composite partition key and a clustering column, insert location events for more than one truck, read one truck's history back in order, deliberately trigger the same partition-key rejection this Act's central lesson chapter demonstrated, update a delivery status, delete an old record, and set an explicit consistency level.
What Your Fleet-Tracking Keyspace Needs
- One table (CREATE TABLE) with a composite partition key of at least two columns (e.g. region and truck_id) and at least one clustering column (e.g. event_time) — the same shape the wide-column modelling chapter built.
- Location events inserted for at least two different partitions (two different region/truck_id combinations) — real, distinct partitions, not one.
- One SELECT that correctly filters every partition-key column with "=" and uses ORDER BY on the clustering column.
- One SELECT attempt that deliberately omits a partition-key column — it should be refused, on purpose, the same way the wide-column modelling chapter's own example was.
- One UPDATE and one DELETE, each filtering the full primary key (partition key columns plus the clustering column).
- An explicit CONSISTENCY level set at least once (ONE, QUORUM, or ALL).
Stuck? A Few Hints
- Reread wide-column-modelling's own two code examples — the composite partition key and the refusal — this checkpoint reuses the exact same shape, just against your own keys.
- The rejected SELECT returning an error is the checkpoint working correctly, not a bug in your script — that's exactly what Cassandra is supposed to do when a query doesn't name every partition-key column.
- Check the "Table state (grouped by partition)" panel after running your INSERTs — it shows your rows as real, separate partitions, which is the fastest way to confirm your partition key is actually doing what you think it is.
Ready to Build It?
Opens the Playground, right in your browser — nothing to install.
Every command should return a real result — a created table, an inserted/updated/deleted row count, or a list of matched rows. The SELECT that omits a partition-key column should come back as an error naming exactly which column is missing — that's the checkpoint working correctly, not a sign something went wrong.
Before You Move On
A composite partition key, real partitions you can see grouped in the output, a query that succeeds because it respects the partition boundary and one that's refused because it doesn't, an update, a delete, and an explicit consistency choice — that's the whole Act, in one script: design around distribution first, and let the table's shape follow from the question the truck actually asks. The next Act moves from a database GreenMart runs itself into the relationships between GreenMart's own data — the part no wide-column table was ever built to answer.