`getByTaskId()` takes an array of strings. It is parsed into task prefix (e.g.
"TA") and task_id. The database is then queried on an array of task_ids.
The result is wrapped in an object with a status code. Currently, the
code is hardcoded as "ok", but can be fleshed out when additional
features are implemented.
There are a few features missing:
- Validation that each string is the right length
- Validation that syntactically valid prefixes and ids were passed
- A check that all requested records are returned
- A check that task prefixes actually exist in the config (requires
implementing the config module)
- Proper status codes
`getByDbId()` takes and array of id numbers. The database is then
queried with this array. The results are wrapped as above.
Missing features:
- A check that all requested records are returned
- Proper status codes
Both methods return `{status: "failed", error}` when the database
request throws an error.
The script updates task related tables only at this time.
Arguments "seed" and "reset" can be passed. "seed" accepts a flag
"--count" which specifies a custom number of task entries to generate.
"task_types" are currently fixed at TA and PC.
To account for db adapter limitations, the script will automatically
batch databse entries by 500 requests.
Database interactions will be handled by service classes. Service
classes will be called by page load functions as well as by API
endpoints. This will allow one source of truth for authorization and
data validation.
One of the sql generations mistakenly looked for a field value of '?'.
Whatever code was causing this to occur is no longer an issue. This does
highlight the difficulty of needing to delete or modify faulty migration
files.
