Skip to main content

FlagStore

Trait FlagStore 

Source
pub trait FlagStore:
    Send
    + Sync
    + 'static {
    // Required methods
    fn name(&self) -> &'static str;
    fn get<'a>(
        &'a self,
        flag: &'a str,
        scope: &'a Scope,
    ) -> BoxFuture<'a, Result<Option<bool>>>;
    fn set<'a>(
        &'a self,
        flag: &'a str,
        scope: &'a Scope,
        value: bool,
    ) -> BoxFuture<'a, Result<()>>;
    fn forget<'a>(
        &'a self,
        flag: &'a str,
        scope: &'a Scope,
    ) -> BoxFuture<'a, Result<()>>;
    fn flush(&self) -> BoxFuture<'_, Result<()>>;
}
Expand description

Somewhere overrides are kept.

Every method is keyed by a (flag, scope) pair, and the store is free to key its rows however it likes as long as Scope::key distinctions are preserved — a user and a tenant with the same name are two subjects.

Required Methods§

Source

fn name(&self) -> &'static str

The store’s name, for error messages and boot logs.

Source

fn get<'a>( &'a self, flag: &'a str, scope: &'a Scope, ) -> BoxFuture<'a, Result<Option<bool>>>

The override for one flag and scope: None when nobody has set one.

None and Some(false) are emphatically not the same answer. None means “no opinion, ask the resolver”; Some(false) means “somebody turned this off”. A store that collapses the two turns every override into a suggestion.

Source

fn set<'a>( &'a self, flag: &'a str, scope: &'a Scope, value: bool, ) -> BoxFuture<'a, Result<()>>

Write an override, replacing any that was there.

Source

fn forget<'a>( &'a self, flag: &'a str, scope: &'a Scope, ) -> BoxFuture<'a, Result<()>>

Remove an override, putting the flag back in the resolver’s hands.

Not an error when there was nothing to remove: an operator clearing an override they are not sure they set wants it gone either way.

Source

fn flush(&self) -> BoxFuture<'_, Result<()>>

Remove every override this store holds.

Worth being careful with. It does not “reset the flags” — it deletes every decision an operator ever recorded, including the ones holding a feature off, and the next request resolves them all from scratch.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§