Struct TuneResultRow 

pub struct TuneResultRow {
    pub id: i64,
    pub run_id: i64,
    pub response_level: ResponseLevel,
    pub kp: Option<f32>,
    pub ti_minutes: Option<f32>,
    pub td_minutes: Option<f32>,
    pub proportional: Option<f32>,
    pub integral: Option<f32>,
    pub derivative: Option<f32>,
    pub status: TuningResultStatus,
    pub invalid_reason: Option<TuningResultInvalidReason>,
}

One row of tune_results: the calculated PID result for one ResponseLevel of one run.

Flattened rather than nesting TuningResult/PidParameters directly, since both of those types carry their own response_level field — nesting both would mean either two redundant copies that could disagree, or an awkward “just trust the outer one” rule. One flat set of columns matching the table exactly avoids that.

Fields

id: i64

run_id: i64

response_level: ResponseLevel

kp: Option<f32>

ti_minutes: Option<f32>

td_minutes: Option<f32>

proportional: Option<f32>

integral: Option<f32>

derivative: Option<f32>

status: TuningResultStatus

invalid_reason: Option<TuningResultInvalidReason>

Implementations

impl TuneResultRow

pub fn from_calculated( run_id: i64, tuning: TuningResult, pid: PidParameters, ) -> TuneResultRow

Builds a (not-yet-inserted, id = 0) row from a matching TuningResult/ PidParameters pair, as produced together by bhtune_core::tuning_math::calculate_tuning_result/ bhtune_core::tuning_math::calculate_pid_parameters for the same ResponseLevel.

Panics

Panics if tuning.response_level != pid.response_level: pairing results for different response levels together is always a caller bug, never a runtime data problem, the same contract bhtune_core::tuning_math::measure_oscillation documents for its own caller-contract panics.

pub fn from_checked(run_id: i64, checked: CheckedTuningResult) -> TuneResultRow

Builds a row from the checked calculation path. Invalid results retain their response level and reason while leaving every numeric value absent, so they cannot be mistaken for writable PID constants.

pub async fn insert( pool: &SqlitePool, row: &TuneResultRow, ) -> DbResult<TuneResultRow>

Inserts row (typically built via Self::from_calculated), returning the persisted copy with its assigned id. (run_id, response_level) is unique (see the migration) — a successfully completed run writes exactly the 3 ResponseLevel rows once, at completion.

pub async fn list_for_run( pool: &SqlitePool, run_id: i64, ) -> DbResult<Vec<TuneResultRow>>

Lists every calculated result of run_id, ordered by ResponseLevel (which sorts alphabetically as Aggressive, Moderate, Sluggish — the same order bhtune_core::constants::ResponseLevel::ALL enumerates them in). 0 rows for a run that never completed, up to 3 for one that did.

Trait Implementations

impl Clone for TuneResultRow

fn clone(&self) -> TuneResultRow

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Copy for TuneResultRow

impl Debug for TuneResultRow

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

Formats the value using the given formatter.

impl PartialEq for TuneResultRow

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

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

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 TuneResultRow