ores.compute.workunit
Table of Contents
Defines the problem to be solved: which app version to use, where the input data lives, and how many times to run it for redundancy. The BOINC equivalent of 'workunit'. Does not track execution state — that belongs to results.
1. Flags
The workunit's key is its id. An earlier version of this model said
:key_field: input_uri, and that made a multi-job batch impossible: every
workunit of a batch runs the same input bundle, so the second workunit of
a batch was refused as an existing row. The end-to-end run found it.
2. Columns
2.1. id
UUID primary key for the workunit.
2.2. batch_id
FK reference to ores_compute_batches_tbl.
2.3. app_version_id
FK reference to ores_compute_app_versions_tbl.
2.4. input_uri
URI pointing to the zipped input data bundle in object storage.
2.5. config_uri
URI pointing to the engine config file (ORE XML, Llama JSON, etc.).
2.6. priority
Scheduling priority; higher values are dispatched sooner.
2.7. target_redundancy
Number of independent results required before this workunit is complete.
2.8. canonical_result_id
FK to the validated canonical result; NULL until the Validator accepts a result.
3. Foreign keys
3.1. batch_id
3.2. app_version_id
3.3. canonical_result_id
4. SQL
4.1. Flags
5. C++
5.1. Flags
5.2. Repository
5.3. Domain includes
#include <string> #include <boost/uuid/uuid.hpp>
5.4. Conventions
5.5. Table display
| column | header |
|---|---|
| id | ID |
| batch_id | Batch ID |
| app_version_id | App Version ID |
| input_uri | Input URI |
| config_uri | Config URI |
| priority | Priority |
| target_redundancy | Target Redundancy |
| modified_by | Modified By |
| recorded_at | Recorded At |
5.6. Custom repository methods
6. See also
- ores.compute — component group overview.