apxtri/data

data/ — versioned runtime data (reference objects)

This directory holds the reference data of an apxtri instance or tribe. It is versioned in the repository so that a new instance starts with the same data as an existing one, and so that a change to a reference object can be rolled out to every town by a plain git pull followed by setup/update.sh.

Nothing in here is user data. Persons, messages, clients, missions, and any other runtime content are never committed to this directory: --apply refuses to write objects that are not on the whitelist (see setup/sync-data.sh).

Layout

data/
├── objects/            # Reference Odmdb objects (annule et remplace)
│   └── options/
│       └── itm/*.json  # e.g. profil_en.json, conditiontojoin_fr.json
├── apidoc/             # apidoc webapp config, rendered at install time
│   └── apxtri/{appconf.json,header.md,footer.md}
└── wwws/               # On-demand templates, never applied by update
    └── newwebapp/

Rules

Source	Rule	Target
data/objects/	Overwrite, never delete	{DATAPATH}/{TOWN}/objects/
{tribe}/data/objects/	Overwrite, never delete	{DATAPATH}/{tribe}/objects/
apxtri/data/apidoc/	Render Mustache, then overwrite	{DATAPATH}/{TOWN}/wwws/apidoc/
apxtri/data/wwws/*	Nothing — used on demand	—
{tribe}/data/wwws/*	Nothing — used on demand	—

overwrite means: the file present in the repository replaces the file of the same name in the runtime. It never means a directory synchronisation — files absent from data/ are left untouched in {DATAPATH}.

Granularity

The unit is the file. Each option object is one file per language (profil_en.json, profil_fr.json, ...) sharing the same optionid. So you can push a single language variant, or the whole set. Pushing a new value for an option is always a full-file replacement: there is no merge, by design.

sync-data.sh --limit <glob> restricts a run to files matching the glob (e.g. --limit 'profil_*' to touch only the profile options), which is the recommended way to version just what a tribe customises instead of mirroring every town option.

Workflow

Reference data is edited in the running instance, because that is where it can be tested. It is then captured back into the repository and pushed:

# 1. Edit / test the data in the running instance.
#    {DATAPATH}/{TOWN}/objects/options/itm/profil_*.json

# 2. Capture the runtime data into data/ (called automatically by gitpush.sh)
setup/sync-data.sh --capture --tribe apxtri --limit 'profil_*'
#    or, from a tribe repository:
setup/sync-data.sh --capture --tribe edifiance --limit 'profil_*'

# 3. Review, commit and push.
git add data/
git commit -m "data: add supports and experts to profil options"
gitpush.sh patch

On every other instance, a pull plus an update applies the same files:

setup/update.sh

Index files (idx/) are never committed: the runtime rebuilds them on start (apxtri.js → _rebuildIndexes).

Adding a new behaviour

setup/sync-data.sh is the single entry point. Each directory rule is implemented as an isolated function and registered in the rule table, so a new rule is additive: see the "Extending" section of the script documentation.