solverforge-scoring 0.20.3

Incremental constraint scoring for SolverForge
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144

/* Explicit relational fixtures for independent-key join verification.

These types are test-domain stand-ins, not the reporter's model: field
names and weights here are chosen for the regression suite, never inferred
from user code. The two relationships use deliberately disjoint key
domains (`u32` shift ids vs `String` employee codes) so any shared-key
conflation is observable instead of accidentally passing.
*/

use solverforge_core::score::SoftScore;
use solverforge_core::PlanningSolution;

#[derive(Clone, Debug, Hash, PartialEq, Eq)]
pub(super) struct RelShift {
    pub(super) id: u32,
    pub(super) night: bool,
}

#[derive(Clone, Debug, Hash, PartialEq, Eq)]
pub(super) struct RelAssignment {
    pub(super) shift_id: u32,
    pub(super) employee_code: String,
}

#[derive(Clone, Debug, Hash, PartialEq, Eq)]
pub(super) struct RelEmployee {
    pub(super) code: String,
}

#[derive(Clone)]
pub(super) struct RelSchedule {
    pub(super) shifts: Vec<RelShift>,
    pub(super) assignments: Vec<RelAssignment>,
    pub(super) employees: Vec<RelEmployee>,
    pub(super) score: Option<SoftScore>,
}

impl PlanningSolution for RelSchedule {
    type Score = SoftScore;

    fn score(&self) -> Option<Self::Score> {
        self.score
    }

    fn set_score(&mut self, score: Option<Self::Score>) {
        self.score = score;
    }
}

pub(super) fn rel_shifts(schedule: &RelSchedule) -> &[RelShift] {
    schedule.shifts.as_slice()
}

pub(super) fn rel_assignments(schedule: &RelSchedule) -> &[RelAssignment] {
    schedule.assignments.as_slice()
}

pub(super) fn rel_employees(schedule: &RelSchedule) -> &[RelEmployee] {
    schedule.employees.as_slice()
}

/* Canonical sample: two independent relationships over disjoint domains.

R1 (u32): assignment.shift_id == shift.id.
R2 (String): assignment.employee_code == employee.code.

Rows (assignment, shift, employee) with the night-shift filter applied:
- (a0, s0, e0): shift 10 night, emp "e0" -> match.
- (a1, s1, e1): shift 11 day, emp "e1" -> filtered out.
- (a2, s0, e0): duplicate of a0's keys, distinct row identity -> match.
*/
pub(super) fn sample() -> RelSchedule {
    RelSchedule {
        shifts: vec![
            RelShift {
                id: 10,
                night: true,
            },
            RelShift {
                id: 11,
                night: false,
            },
        ],
        assignments: vec![
            RelAssignment {
                shift_id: 10,
                employee_code: "e0".to_string(),
            },
            RelAssignment {
                shift_id: 11,
                employee_code: "e1".to_string(),
            },
            RelAssignment {
                shift_id: 10,
                employee_code: "e0".to_string(),
            },
        ],
        employees: vec![
            RelEmployee {
                code: "e0".to_string(),
            },
            RelEmployee {
                code: "e1".to_string(),
            },
        ],
        score: None,
    }
}

/* Coincidence sample: shift ids rendered as strings collide with employee
codes, so a shared string key domain merges the two relationships and
admits a spurious (a0, s0, e1) row where "10" is treated as one domain.
The oracle rejects it; only (a0, s0, e0) is a real match.
*/
pub(super) fn coincidence_sample() -> RelSchedule {
    RelSchedule {
        shifts: vec![RelShift {
            id: 10,
            night: true,
        }],
        assignments: vec![RelAssignment {
            shift_id: 10,
            employee_code: "e0".to_string(),
        }],
        employees: vec![
            RelEmployee {
                code: "e0".to_string(),
            },
            RelEmployee {
                code: "10".to_string(),
            },
        ],
        score: None,
    }
}

// Shared relationship keys for the fixtures' assignment↔shift topology.
pub(super) fn assignment_key(assignment: &RelAssignment) -> u32 {
    assignment.shift_id
}

pub(super) fn shift_key(shift: &RelShift) -> u32 {
    shift.id
}