Paths

The distribution of data among a CloudB network follows the paradigm of as graph, where are present nodes, each one with different roles (masters, roots and blocks): a single database spans among several nodes of the network graph to distribute data and provide them to the consumers. Because of the software architecture implemented to accomplish these tasks, we decided to name the data container entities (or database instances) as Paths, name that gives a more precise idea of the concrete implementation and functionalities.

Within a CloudB network there can be several paths, but each one must respect a single data-model, specified at the moment of its creation: the path model (implemented through an API provided specifically) participates to the format of data in the storage system and elaborates integrity at the moment of commit.

Path Types

As briefly specified above, each path instance present in the network must implement a single data-model, that is defined by an implementation of the public interface [[Deveel.Data.Net.IPath|https://github.com/deveel/cloudb/blob/master/src/cloudb/Deveel.Data.Net/IPath.cs]]: this provides common functions to ensure commits are successful among the various nodes where data are processed.

A path instance can be created using external tools (CloudB comes with a command-line application named cadmin that offers this functionality): at that moment the type of the path, in fact the implementation of the interface IPath, must be specified, binding the instance to that type. The library containing the concrete implementation of the path type must be registered in every node running in the network: otherwise the creation process will fail.

(It's planned for a later release to implement a system to register the path type once and distribute it among the network nodes at the time of addition of a new node, automatically).

For those who wish to learn how to implement path types, here you will find a brief guide.

Data Versions

The most crucial moment in which a path is taken in action is the commit time. CloudB is a native transactional system, that means every modification done to the contents of a path can be done within a transaction. Since data committed to a path will be distributed among several nodes (for reasons of replication, parallelization and distribution)m each node is called to give its approval to the success of the commit. In case of a failure during the processing of the data in the node, a [[Deveel.Data.Net.CommitFaultException|https://github.com/deveel/cloudb/blob/master/src/cloudb/Deveel.Data.Net/CommitFaultException.cs]] exception is thrown, indicating the whole system that the transaction must return and no data are persisted into the storage.

When a transaction ends successfully, the current trunk of the path data is marked as old and put into the historical repository (not a physical location, but instead a mark used to rebuild a given version), making the committed version as current. Consumers will be able, if needed, to access specific versions of data, either providing an identification number or a range of dates.