Trait pallet_feeds::feed_processor::FeedProcessor

source ·
pub trait FeedProcessor<FeedId> {
    // Required method
    fn object_mappings(
        &self,
        _feed_id: FeedId,
        object: &[u8],
    ) -> Vec<FeedObjectMapping>;

    // Provided methods
    fn init(&self, _feed_id: FeedId, _data: &[u8]) -> DispatchResult { ... }
    fn put(
        &self,
        _feed_id: FeedId,
        _object: &[u8],
    ) -> Result<Option<FeedMetadata>, DispatchError> { ... }
    fn delete(&self, _feed_id: FeedId) -> DispatchResult { ... }
}
Expand description

§Feed Processor

Feed Processor defines some useful abstractions that are used during the life cycle of the Feed and its objects. We can provide some custom logic specific to the Feed by implementing a Custom Feed Processor.

§Feed Metadata

Before an object is added to Subspace storage, put on Feed processor to give the impl an opportunity to run the object through their custom logic and returns some metadata about the object. Metadata is then stored in the runtime overwriting any metadata of the previous object. The default implementation of Feed processor gives empty metadata about the object.

§Feed object mapping

Feed indexes the objects in the DSN using offsets within the Block the object is present in. object_mappings is the only that must be implemented by the Feed processor. Since DSN is a key value store, there are two different ways keys are derived for given data at the offset within the block

  • Key derived from content. Feeds use BLAKE2b-256 to derive the key for the data at the offset.
  • Key provided by the feed processor. Feed processor implementations can instead provide a key for object at the offset.

§Examples

§Content based addressing with default hasher

use pallet_feeds::feed_processor::{FeedProcessor, FeedObjectMapping};
struct IPFSLike;
impl<FeedId> FeedProcessor<FeedId> for IPFSLike { ///
    fn object_mappings(&self, _feed_id: FeedId, _object: &[u8]) -> Vec<FeedObjectMapping> {
        vec![FeedObjectMapping::Content { offset: 0 }]
    }
}

This implements a Content addressable Feed using default Hasher. The entire object is treated as data and hence the offset is zero.

§Content based addressing using custom Hasher

use sp_runtime::traits::{BlakeTwo256, Hash};
use pallet_feeds::feed_processor::{FeedProcessor, FeedObjectMapping};
struct IPFSLike;
impl<FeedId> FeedProcessor<FeedId> for IPFSLike { ///
    fn object_mappings(&self, _feed_id: FeedId, object: &[u8]) -> Vec<FeedObjectMapping> {
        vec![FeedObjectMapping::Custom { key: BlakeTwo256::hash(object).as_bytes().to_vec(), offset: 0 }]
    }
}

This implements a Content addressable Feed using BlakeTwo256 hasher. The entire object is treated as data and hence the offset is zero.

Required Methods§

source

fn object_mappings( &self, _feed_id: FeedId, object: &[u8], ) -> Vec<FeedObjectMapping>

Returns any object mappings inside the given object

Provided Methods§

source

fn init(&self, _feed_id: FeedId, _data: &[u8]) -> DispatchResult

Initiates a specific Feed with data transparent to FeedProcessor Can be called when re-initializing the feed.

source

fn put( &self, _feed_id: FeedId, _object: &[u8], ) -> Result<Option<FeedMetadata>, DispatchError>

Puts a feed and returns the Metadata if any. This is called once per extrinsic that puts a feed into a given feed stream.

source

fn delete(&self, _feed_id: FeedId) -> DispatchResult

Signals a delete to any underlying feed data.

Implementations on Foreign Types§

source§

impl<FeedId> FeedProcessor<FeedId> for ()

Content addressable feed processor impl Offsets the whole object as content thereby signalling to derive key = hash(object) Put do not provide any metadata.

source§

fn object_mappings( &self, _feed_id: FeedId, _object: &[u8], ) -> Vec<FeedObjectMapping>

Maps the entire object as content.

Implementors§