Struct CreateFeatureInput

#[non_exhaustive]
pub struct CreateFeatureInput {
    pub project: Option<String>,
    pub name: Option<String>,
    pub evaluation_strategy: Option<FeatureEvaluationStrategy>,
    pub description: Option<String>,
    pub variations: Option<Vec<VariationConfig>>,
    pub default_variation: Option<String>,
    pub tags: Option<HashMap<String, String>>,
    pub entity_overrides: Option<HashMap<String, String>>,
}

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

project: Option<String>

The name or ARN of the project that is to contain the new feature.

name: Option<String>

The name for the new feature.

evaluation_strategy: Option<FeatureEvaluationStrategy>

Specify ALL_RULES to activate the traffic allocation specified by any ongoing launches or experiments. Specify DEFAULT_VARIATION to serve the default variation to all users instead.

description: Option<String>

An optional description of the feature.

variations: Option<Vec<VariationConfig>>

An array of structures that contain the configuration of the feature's different variations.

default_variation: Option<String>

The name of the variation to use as the default variation. The default variation is served to users who are not allocated to any ongoing launches or experiments of this feature.

This variation must also be listed in the variations structure.

If you omit defaultVariation, the first variation listed in the variations structure is used as the default variation.

tags: Option<HashMap<String, String>>

Assigns one or more tags (key-value pairs) to the feature.

Tags can help you organize and categorize your resources. You can also use them to scope user permissions by granting a user permission to access or change only resources with certain tag values.

Tags don't have any semantic meaning to Amazon Web Services and are interpreted strictly as strings of characters.

You can associate as many as 50 tags with a feature.

For more information, see Tagging Amazon Web Services resources.

entity_overrides: Option<HashMap<String, String>>

Specify users that should always be served a specific variation of a feature. Each user is specified by a key-value pair . For each key, specify a user by entering their user ID, account ID, or some other identifier. For the value, specify the name of the variation that they are to be served.

This parameter is limited to 2500 overrides or a total of 40KB. The 40KB limit includes an overhead of 6 bytes per override.

Implementations

impl CreateFeatureInput

pub fn project(&self) -> Option<&str>

The name or ARN of the project that is to contain the new feature.

pub fn name(&self) -> Option<&str>

The name for the new feature.

pub fn evaluation_strategy(&self) -> Option<&FeatureEvaluationStrategy>

Specify ALL_RULES to activate the traffic allocation specified by any ongoing launches or experiments. Specify DEFAULT_VARIATION to serve the default variation to all users instead.

pub fn description(&self) -> Option<&str>

An optional description of the feature.

pub fn variations(&self) -> &[VariationConfig]

An array of structures that contain the configuration of the feature's different variations.

If no value was sent for this field, a default will be set. If you want to determine if no value was sent, use .variations.is_none().

pub fn default_variation(&self) -> Option<&str>

The name of the variation to use as the default variation. The default variation is served to users who are not allocated to any ongoing launches or experiments of this feature.

This variation must also be listed in the variations structure.

If you omit defaultVariation, the first variation listed in the variations structure is used as the default variation.

pub fn tags(&self) -> Option<&HashMap<String, String>>

Assigns one or more tags (key-value pairs) to the feature.

Tags can help you organize and categorize your resources. You can also use them to scope user permissions by granting a user permission to access or change only resources with certain tag values.

Tags don't have any semantic meaning to Amazon Web Services and are interpreted strictly as strings of characters.

You can associate as many as 50 tags with a feature.

For more information, see Tagging Amazon Web Services resources.

pub fn entity_overrides(&self) -> Option<&HashMap<String, String>>

Specify users that should always be served a specific variation of a feature. Each user is specified by a key-value pair . For each key, specify a user by entering their user ID, account ID, or some other identifier. For the value, specify the name of the variation that they are to be served.

This parameter is limited to 2500 overrides or a total of 40KB. The 40KB limit includes an overhead of 6 bytes per override.

impl CreateFeatureInput

pub fn builder() -> CreateFeatureInputBuilder

Creates a new builder-style object to manufacture CreateFeatureInput.

Trait Implementations

impl Clone for CreateFeatureInput

fn clone(&self) -> CreateFeatureInput

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for CreateFeatureInput

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

Formats the value using the given formatter.

impl PartialEq for CreateFeatureInput

fn eq(&self, other: &CreateFeatureInput) -> bool

Tests for self and other values to be equal, and is used by ==.

const fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl StructuralPartialEq for CreateFeatureInput