Nominations DB Architecture
Design
This architecture was designed with Crop nominations in mind.
It was also thought that maybe this could be the basis for a platform wide change to pattern most actions done in Litefarm under a workflow > tasks > logs style architecture (to be proposed @Duncan Brain ).
Tables
nomination_type
DESCRIPTION: List of types. A nomination type will have only one workflow group.
nomination_type - Primary Key - String - notes: N/A
Example:
nomination_type | …Base Object |
---|---|
CROP_NOMINATION | … |
CROP_VARIETY_NOMINATION |
|
nomination
DESCRIPTION: List of nominations. A nomination needs a farm_id and a type but does not need an assignee.
nomination_id - Primary Key - Increments - Integer - notes: Linear-ish therefore integer
farm_id - Foreign Key - Not Null - UUID - notes: Consider removing. Necessary for hasFarmAccess(check).
nomination_type - Foreign Key - Not Null - String - notes: Consider using workflow_group instead.
Example:
nomination_id | farm_id | nomination_type | …Base Object |
---|---|---|---|
1 | xxxxxx-xxxx-xxx-xxx | CROP | … |
2 | xxxxxx-xxxx-xxx-xxx | CROP_VARIETY |
|
nomination_workflow
DESCRIPTION: List of workflow groups and status names. Workflows groups many have different steps but same status.
workflow_id - Primary Key - Increments - Integer - notes: No particular order just an id
status - Unique(name, group) - Not Null - String - notes: N/A
type_group - Foreign Key -Unique(name, group) - Not Null - String - notes: N/A
Example:
workflow_id | status | type_group | …Base Object |
---|---|---|---|
1 | REJECTED | CROP_NOMINATION | … |
2 | APPROVED | CROP_NOMINATION |
|
3 | NOMINATED | CROP_NOMINATION |
|
4 | LF_REVIEW | CROP_NOMINATION |
|
5 | EXPERT_REVIEW | CROP_NOMINATION |
|
6 | REJECTED | CROP_VARIETY_NOMINATION |
|
7 | APPROVED | CROP_VARIETY_NOMINATION |
|
8 | NOMINATED | CROP_VARIETY_NOMINATION |
|
9 | VARIETAL_ANALYSIS | CROP_VARIETY_NOMINATION |
|
10 | LF_REVIEW | CROP_VARIETY_NOMINATION |
|
nomination_status
DESCRIPTION: List of status changes. A status needs a timestamp
status_id - Primary Key - UUID - Integer - notes: Exponential-ish therefore uuid
nomination_id - Foreign Key - Not Null - Integer - notes: N/A
workflow_id - Foreign Key - Not Null - String - notes: N/A
notes - Nullable - Text - notes: N/A
BASE_OBJECT_ATTRIBUTES - notes: Consider removing updated_at and updated_by.
Example:
status_id | nomination_id | workflow_id | notes | …Base Object |
---|---|---|---|---|
2 | 1 | 10 | Looks good to me | … |
1 | 1 | 8 | null |
|
Not yet Implemented
Immutable Nominations
Consider the following table to hold the object:
id | nomination_id | nomination_object | …Base Object |
---|---|---|---|
1 | 2 | JSON({crop }) | … |