ores.compute.app_version

Table of Contents

Combines a specific wrapper version with a specific engine version. The BOINC equivalent of 'app_version'. Per-platform package artefacts are tracked in ores_compute_app_version_platforms_tbl — each (app_version, platform) row owns the URI of its own packaged bundle.

1. Flags

The app version's key is its id. An earlier version of this model said :key_field: wrapper_version, and that made two versions of one app that share a wrapper version read each other's row: the version precondition of a write found the first row with that wrapper version, so a second republish of the other version was refused with a version conflict.

2. Columns

2.1. id

UUID primary key for the app version.

2.2. app_id

FK reference to ores_compute_apps_tbl.

2.3. wrapper_version

Version of the OreStudio wrapper binary, e.g. 'v1.2.0'.

2.4. engine_version

Version of the underlying engine, e.g. 'ORE-Studio-7.1'.

2.5. min_ram_mb

Minimum RAM in MB required by the node to run this app version.

2.6. release_note

Release note of the release this app version belongs to, as plain text. One release is one engine build and one wrapper build, packaged for several platforms, and one note describes it. An empty note means none was written.

3. Foreign keys

3.1. app_id

4. SQL

4.1. Flags

5. C++

5.1. Flags

5.2. Repository

App versions inherit their parent app's system-tenant visibility: the platform's canonical apps ship with platform-managed versions, and every tenant must see them in reads. Mutations stay own-tenant scoped.

5.3. Domain includes

#include <string>
#include <boost/uuid/uuid.hpp>

5.4. Conventions

5.5. Table display

column header
id ID
app_id App ID
wrapper_version Wrapper Version
engine_version Engine Version
min_ram_mb Min RAM (MB)
modified_by Modified By
recorded_at Recorded At

5.6. Custom repository methods

6. See also

Emacs 29.3 (Org mode 9.6.15)