Prices and quantities in a game list change over time. Treating every edit as a different installation would make its fault reports and earlier changes difficult to follow. In August, stable installation IDs were separated from time-specific values, and whole-list replacement requests became explicit additions, modifications and removals.

Collaborative editing and whole-list saves

Several people can edit an arcade document. For example, two visitors might open the same list, one changing a price and the other a quantity. Saving each complete copy can undo the first edit when the second arrives. The server needs both the requested changes and the state on which they were based.

The previous game-entry screen. Changes needed to be identified per item and compared with prior values. Original English capture.

Generating new item IDs on every save creates another problem. A price or quantity change still concerns the same installation, yet its reports and history would lose their reference. Structured history requires save requests to identify both that continuing item and the editing baseline.

flowchart TD
    accTitle: Two facts whole-list replacement can lose
    accDescr: Resaving a complete list requires item identity and the state it was read from; without them references and concurrent edits are hard to validate.
    A[Read and edit the list] --> B[Whole-list replacement request]
    B --> C[Identify the same item]
    B --> D[Check the original base state]

Installation IDs and versioned values

arcade_game_id continuously identifies an installation within an arcade. A revision stores its version, quantity, price and other values at a point in time. Catalog IDs describe product types and compatibility; this ID describes a particular arcade installation.

A fault report’s game_id references that installation ID. Edits need not copy the full game payload into every report. Earlier values remain in revisions, while reports continue to identify the same physical target.

flowchart LR
    accTitle: Separating identity from time-specific values
    accDescr: Revisions in the current batch reference a persistent game-item ID; earlier revisions and fault reports use the same ID.
    A[arcade.game_v2] --> B[Current batch]
    B --> R[Current revision]
    R --> I[arcade_game_id]
    O[Past revision] --> I
    F[Fault reports] --> I

A batch represents a complete game-list configuration at one point. arcade.game_v2 points to the current batch, and earlier batches and revisions remain. Requests contain add, modify and remove operations so the server can identify what actually changed.

Saving changes and handling conflicts

The editor sends its starting batch as base_state_id. Within a transaction, the server verifies permission and the current batch, applying changes only when the baseline matches. New batches and revisions, the current reference and change history save together.

sequenceDiagram
    accTitle: Two edits starting from A
    accDescr: After the first editor saves B with its pointer and history the server returns 409 to the second edit based on A.
    participant E1 as Editor 1
    participant S as Server
    participant E2 as Editor 2
    S-->>E1: Current batch A
    S-->>E2: Current batch A
    E1->>S: Base A and changes
    Note over S: Save B pointer and history together
    S-->>E1: Saved B
    E2->>S: Base A and changes
    S-->>E2: 409 Conflict

For example, if two editors start from A and the first save creates B, the second request still based on A receives 409 Conflict. The interface preserves its draft. It does not silently replace the baseline ID or automatically merge changes; the contributor can review the latest configuration alongside their intended edit.

Restoring configurations and storage costs

An installation remains identifiable when its quantity changes from two to three, preserving links to reports and history. Restoration verifies editing permission and that the selected record belongs to the arcade, then points the current selection to an earlier batch. It chooses a retained configuration rather than reconstructing individual values.

flowchart LR
    accTitle: Restoration that retains past states
    accDescr: Move the current pointer to an earlier batch and record the transition in new history while retaining batches and existing history.
    P[Current pointer] -->|After restoration| A[Past batch A]
    P -.->|Before restoration| B[Recent batch B]
    L[New restoration history] -->|Previous| B
    L -->|Next| A

Restoring B to A retains B and the earlier A→B history, adding a new B→A entry. The route to the current configuration remains inspectable. This costs revision storage even for small edits, and a changed batch conflicts even when editors touched different items. Preventing silent overwrites takes priority over automatic merging.

Related articles and sources: Structured edit history · Fault reports · Musecat engineering notes