Basic: Validation
Background
In this exercise we will implement validation. Validation ensures that only valid data ends up on the chain used by an agent's hApp.
This hApp estimates work items. Agents can submit an Estimate
with an estimate value:
pub struct Estimate {
item: String,
value: u8,
}
Our hApp has one requirement: all estimates must conform to the agile estimation recommendation of using Fibonacci numbers less than or equal to 21. (Here's an agile estimation Fibonacci explainer).
let valid_estimate_values = vec![0, 1, 2, 3, 5, 8, 13, 21];
So in addition to the add_estimate
zome function allowing us to create new estimates, we will also
implement the validate
zome function that ensures that only valid data is saved to the source chain.
About validation
If your zome implements a validate
function, the conductor will call it for all changes to the DHT
for any cell containing the zome.
The argument your validate
will receive is an
holochain_integrity_types::op::Op
.
Op
is short for "DHT Operation". Every time you commit some action in your source chain, multiple DHT Operations are created and published to different parts of the DHT. This is because different read operations need to read different parts of the DHT, so we need to store the same element in multiple places.
This is a table describing the "DhtOps" that each action creates:
Chain Action | DhtOp Name | Targeted hash basis | Payload | Metadata |
---|---|---|---|---|
create_content(content) | RegisterAgentActivity StoreRecord StoreContent | Author's public key Hash of the action Hash of the content | Action Record Record | Hash of the action - - |
update_content(original_action_hash, new_content) | RegisterAgentActivity StoreRecord StoreContent RegisterContentUpdate RegisterRecordUpdate | Author's public key Hash of the action Hash of the content Hash of the original content Hash of the original action | New action New Record New record New action New action | Hash of the action - New content updates old content Old content is updated to new content Old action is updated to new action |
bury_content(action_hash) | RegisterAgentActivity StoreRecord RegisterContentDelete RegisterRecordDelete | Author's public key Hash of the new action Hash of the deleted content Hash of the deleted action | New action New Record New action New action | Hash of the action - Old content deleted by new action Old action deleted by new action |
create_link(base, target, tag) | RegisterAgentActivity StoreRecord RegisterCreateLink | Author's public key Hash of the new action "Base" hash | Action Record Action | Hash of the action - Link from the base to the target hash |
delete_link(create_link_action_hash) | RegisterAgentActivity StoreRecord RegisterDeleteLink | Author's public key Hash of the new action Hash of the deleted create link action hash | Action Record Action | Hash of the action - Deleted link sent to tombstone |
After the action is committed to the source chain and published to the DHT in those different parts, the agents who receive those publish requests first have to validate that the DHT Operation is actually valid and playing by the rules of the game. After making sure that the change is valid, the agents will start to answer DHT read operations (get
, get_links
, etc.) with its data.
To know more about how to implement validation rules in your application, read this documentation.
Exercise
We have provided the basic structure of validating a DNA that allows the creation of Estimate
s.
Your task is to add the validation business logic for the Estimate
s:
- An Estimate value must be an agile Fibonacci value.
- An Estimate's
item
must be non-empty.
Extra credit
Add this validation rule:
- Each agent can only estimate the same
item
once.