Struct ruarango::coll::input::Config

pub struct Config { /* private fields */ }

Configuration used when creating a collection

Implementations

impl Config

pub fn name(&self) -> &String

The collection name

pub fn journal_size(&self) -> &Option<usize>

The maximal size of a journal or datafile in bytes. The value must be at least 1048576 (1 MiB). (The default is a configuration parameter) This option is meaningful for the MMFiles storage engine only.

pub fn replication_factor(&self) -> &Option<String>

(The default is 1): in a cluster, this attribute determines how many copies of each shard are kept on different DB-Servers. The value 1 means that only one copy (no synchronous replication) is kept. A value of k means that k-1 replicas are kept. It can also be the string “satellite” for a SatelliteCollection, where the replication factor is matched to the number of DB-Servers (Enterprise Edition only). Any two copies reside on different DB-Servers. Replication between them is synchronous, that is, every write operation to the “leader” copy will be replicated to all “follower” replicas, before the write operation is reported successful. If a server fails, this is detected automatically and one of the servers holding copies take over, usually without an error being reported.

pub fn key_options(&self) -> &Option<KeyOptions>

Key Options

pub fn wait_for_sync(&self) -> &Option<bool>

If true then the data is synchronized to disk before returning from a document create, update, replace or removal operation. (default: false)

pub fn do_compact(&self) -> &Option<bool>

Whether or not the collection will be compacted (default is true) This option is meaningful for the MMFiles storage engine only.

pub fn sharding_strategy(&self) -> &Option<String>

This attribute specifies the name of the sharding strategy to use for the collection. Since ArangoDB 3.4 there are different sharding strategies to select from when creating a new collection. The selected shardingStrategy value will remain fixed for the collection and cannot be changed afterwards. This is important to make the collection keep its sharding settings and always find documents already distributed to shards using the same initial sharding algorithm. The available sharding strategies are: community-compat: default sharding used by ArangoDB Community Edition before version 3.4 enterprise-compat: default sharding used by ArangoDB Enterprise Edition before version 3.4 enterprise-smart-edge-compat: default sharding used by smart edge collections in ArangoDB Enterprise Edition before version 3.4 hash: default sharding used for new collections starting from version 3.4 (excluding smart edge collections) enterprise-hash-smart-edge: default sharding used for new smart edge collections starting from version 3.4 If no sharding strategy is specified, the default will be hash for all collections, and enterprise-hash-smart-edge for all smart edge collections (requires the Enterprise Edition of ArangoDB). Manually overriding the sharding strategy does not yet provide a benefit, but it may later in case other sharding strategies are added.

pub fn is_volatile(&self) -> &Option<bool>

If true then the collection data is kept in-memory only and not made persistent. Unloading the collection will cause the collection data to be discarded. Stopping or re-starting the server will also cause full loss of data in the collection. Setting this option will make the resulting collection be slightly faster than regular collections because ArangoDB does not enforce any synchronization to disk and does not calculate any CRC checksums for datafiles (as there are no datafiles). This option should therefore be used for cache-type collections only, and not for data that cannot be re-created otherwise. (The default is false) This option is meaningful for the MMFiles storage engine only.

pub fn write_concern(&self) -> &Option<usize>

Write concern for this collection (default: 1). It determines how many copies of each shard are required to be in sync on the different DB-Servers. If there are less then these many copies in the cluster a shard will refuse to write. Writes to shards with enough up-to-date copies will succeed at the same time however. The value of writeConcern can not be larger than replicationFactor. (cluster only)

pub fn smart_join_attribute(&self) -> &Option<String>

In an Enterprise Edition cluster, this attribute determines an attribute of the collection that must contain the shard key value of the referred-to SmartJoin collection. Additionally, the shard key for a document in this collection must contain the value of this attribute, followed by a colon, followed by the actual primary key of the document. This feature can only be used in the Enterprise Edition and requires the distributeShardsLike attribute of the collection to be set to the name of another collection. It also requires the shardKeys attribute of the collection to be set to a single shard key attribute, with an additional ‘:’ at the end. A further restriction is that whenever documents are stored or updated in the collection, the value stored in the smartJoinAttribute must be a string.

pub fn number_of_shards(&self) -> &Option<usize>

(The default is 1): in a cluster, this value determines the number of shards to create for the collection. In a single server setup, this option is meaningless.

pub fn distribute_shards_like(&self) -> &Option<String>

(The default is “”): in an Enterprise Edition cluster, this attribute binds the specifics of sharding for the newly created collection to follow that of a specified existing collection. Note: Using this parameter has consequences for the prototype collection. It can no longer be dropped, before the sharding-imitating collections are dropped. Equally, backups and restores of imitating collections alone will generate warnings (which can be overridden) about missing sharding prototype.

pub fn is_system(&self) -> &Option<bool>

If true, create a system collection. In this case collection-name should start with an underscore. End users should normally create non-system collections only. API implementors may be required to create system collections in very special occasions, but normally a regular collection will do. (The default is false)

pub fn kind(&self) -> &Option<usize>

(The default is 2): the type of the collection to create. The following values for type are valid: 2: document collection 3: edge collection

pub fn shard_keys(&self) -> &Option<Vec<String>>

(The default is [ “_key” ]): in a cluster, this attribute determines which document attributes are used to determine the target shard for documents. Documents are sent to shards based on the values of their shard key attributes. The values of all shard key attributes in a document are hashed, and the hash value is used to determine the target shard. Note: Values of shard key attributes cannot be changed once set. This option is meaningless in a single server setup.

pub fn schema(&self) -> &Option<String>

Optional object that specifies the collection level schema for documents. The attribute keys rule, level and message must follow the rules documented in Document Schema Validation

Trait Implementations

impl Clone for Config

fn clone(&self) -> Config

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Config

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Config

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>where
    __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Serialize for Config

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>where
    __S: Serializer,

Serialize this value into the given Serde serializer.