Module hdk::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 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.

Macros

Implements conversion traits to allow a struct to be handled as an app entry. If you have some need to implement custom serialization logic or metadata injection you can do so by implementing these traits manually instead.

Functions

General function that can create any entry type.

Create an app entry. Also see create.

General function that can delete any entry type.

Delete an app entry. Also see delete.

Gets a record for a given entry or action hash.

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 a SignedActionHashed at a given ActionHash.

MUST get an EntryHashed at a given EntryHash.

MUST get a VALID Record at a given ActionHash.

General function that can update any entry type.

Update an app entry. Also see update.

Attribute Macros

Declares the integrity zome’s entry types.

Helper for entry data types.