Module entry

Source
Expand description

Working with app and system entries.

Most Holochain applications will define their own app entry types.

App entries are all entries that are not system entries. Definitions of entry types belong in the integrity zomes of a DNA. In contrast, operations for manipulating entries go into coordinator zomes.

§Examples

Refer to the WASM workspace in the Holochain repository for examples. Here’s a simple example of an entry definition: https://github.com/holochain/holochain/blob/develop/crates/test_utils/wasm/wasm_workspace/entry_defs/src/integrity.rs

An example of a coordinator zome with functions to manipulate entries: https://github.com/holochain/holochain/blob/develop/crates/test_utils/wasm/wasm_workspace/coordinator_zome/src/lib.rs

§CRUD

CRUD in Holochain is represented as a graph/tree of Records referencing each other (via Action hashes), representing new states of a shared identity. Because the network is always subject to the possibility of partitions, there is no way to assert an objective truth about the ‘current’ or ‘real’ value that all participants will agree on. This is a key difference between Holochain and blockchains. Where blockchains define a consensus algorithm that brings all participants as close as possible to a single value, while Holochain lets each participant discover their own truth.

The practical implication of this is that agents fetch as much information as they can from the network, then follow an algorithm to ‘walk’ or ‘reduce’ the revisions and discover ‘current’ for themselves.

In Holochain terms, blockchain consensus is walking all the known ‘updates’ (blocks) that pass validation, then walking/reducing down them to disover the ‘chain with the most work’ or similar. For example, to implement a blockchain in Holochain, attach a proof of work to each update and then follow the updates with the most work to the end.

There are many other ways to discover the correct path through updates, for example a friendly game of chess between two players could involve consensual re-orgs or ‘undos’ of moves by countersigning a different update higher up the tree, to branch out a new revision history.

Two agents with the same information may even disagree on the ‘correct’ path through updates and this may be valid for a particular application. For example, an agent could choose to ‘block’ another agent and ignore all their updates.

Functions§

create
General function that can create any entry type.
create_entry
Create an app entry. Also see create.
delete
General function that can delete any entry type.
delete_entry
Delete an app entry. Also see delete.
get
Gets a record for a given entry or action hash.
get_details
Get a record and its details for the entry or action hash passed in. Returns None if the entry/action does not exist. The details returned are a contextual mix of records and action hashes.
must_get_action
MUST get a SignedActionHashed at a given ActionHash.
must_get_entry
MUST get an EntryHashed at a given EntryHash.
must_get_valid_record
MUST get a VALID Record at a given ActionHash.
update
General function that can update any entry type.
update_entry
Update an app entry. Also see update.

Attribute Macros§

hdk_entry_helper
Helper for entry data types.
hdk_entry_types
Declares the integrity zome’s entry types.