← All workshopsRead Change the Requested Jobs Without Rewriting the Rest

SQL

Close one job without changing its neighbours

BOTIE

Connect the original queue and selector to Match every named selector field. Inspect the selected IDs before applying the patch.
Ready to test
0 passed · 0 failed · 2 not run

An empty floor. Start with the information your machine needs.

Received result

Your answer will arrive here.

Examples, experiments and workspace controls
Live values

Connect a tool's inputs to see what it produces. You can try a branch before connecting it to Result.

Try your own inputs

Use a copy of the example to try your own data. Keep the problem's assumptions in mind, and predict the effect of a change before checking the output. You can also add another branch to compare two ways of doing the calculation.

Start at an output arrow, then click or drag to an input. Drag empty space to pan. Delete removes a selection. Ctrl/Cmd+Z undoes a change.
Context for this challenge

Connect the original queue and selector to Match every named selector field. Inspect the selected IDs before applying the patch.

A status update belongs to one selected job.

Inspect the component calculation
Match every named selector field(
  Records: Current queue
  Exact selector: Write predicate
)
Examples and results
Current queue
[
  {
    "id": "J1",
    "status": "open"
  },
  {
    "id": "J2",
    "status": "open"
  }
]
Write predicate
{
  "id": "J1"
}
Required result
[
  {
    "id": "J1",
    "status": "open"
  }
]
Current queue
[
  {
    "id": "J1",
    "status": "cancelled"
  }
]
Write predicate
{
  "id": "J1",
  "status": "open"
}
Required result
[]
Try a fresh construction

This clears this draft, including its undo history. Earlier successful attempts stay recorded. Build again without opening hints to record an independent attempt.

Stuck? Inspect a worked construction

The tools below form one possible solution. You can assemble it, follow its signals, and undo that change to return to your own construction.

Assumptions and test precision

This is a record transformation. Atomicity and concurrent database writes require the SQL mechanisms in the next lessons. Numerical tests allow a difference of 0.001. Lists and structures must also have the right shape.

Your last tested pieces can start the full construction. An existing draft there keeps its own pieces.

A tenant-and-state predicate selects one job

This check uses the pieces from “Select, patch and merge the intended records”.

BOTIE

Only north’s open jobs should move to assigned. North’s completed job and south’s open job must retain their statuses. Predict the complete queue.
Current queue
[
  {
    "id": "J4",
    "tenant": "north",
    "status": "open"
  },
  {
    "id": "J5",
    "tenant": "north",
    "status": "done"
  },
  {
    "id": "J6",
    "tenant": "south",
    "status": "open"
  }
]
Write predicate
{
  "tenant": "north",
  "status": "open"
}
Replacement values
{
  "status": "assigned"
}

Use a number, text, or an array matching the requested result. For a matrix, put each row in brackets. Saving your prediction runs your current construction on these inputs and checks the earlier examples too.

Build a construction in the workspace above first. This case will test those pieces.

What extra predicate would prevent an old open-to-done decision from closing a job that was cancelled meanwhile?

Keep preconditions in the actual write and inspect whether any record matched.

This is a record transformation. Atomicity and concurrent database writes require the SQL mechanisms in the next lessons.

Work through the SQL challenges →
Continue the courseMove Spare Parts Without Losing Half the Transfer →
← Why Must a Pump Move Be Edited on Every Job?