Skip to content

Add benchmark aliases for multiple exact-match identifiers#742

Open
Louisvranderick wants to merge 1 commit intobencherdev:develfrom
Louisvranderick:benchmark-alias
Open

Add benchmark aliases for multiple exact-match identifiers#742
Louisvranderick wants to merge 1 commit intobencherdev:develfrom
Louisvranderick:benchmark-alias

Conversation

@Louisvranderick
Copy link
Copy Markdown
Contributor

Summary

  • Add a new benchmark_alias table with UNIQUE(project_id, alias) and cascading foreign keys so benchmarks can keep multiple exact-match aliases over time.
  • Resolve benchmark NameId::Name by primary name or alias (single query with OR EXISTS), and validate alias uniqueness inside create/update write transactions to avoid TOCTOU races.
  • Expose aliases through API + generated types, wire CLI create/update --alias, and batch-load aliases in list/report paths to avoid N+1 query behavior.

Closes #674

Test plan

  • cargo fmt
  • cargo clippy -p bencher_schema -p api_projects -p bencher_cli --no-deps --all-targets --all-features -- -Dwarnings
  • cargo test -p bencher_schema model::project::benchmark
  • cargo check --no-default-features
  • cargo gen-types outputs committed (services/api/openapi.json, services/console/src/types/bencher.ts)

Made with Cursor

Add a `benchmark_alias` table so benchmarks can be resolved by
alternative names in addition to their primary name, slug, or UUID.
This lets users rename benchmarks over time without losing continuity.

- New `benchmark_alias` migration with UNIQUE(project_id, alias) and
  cascading deletes
- Split `benchmark.rs` into `benchmark/mod.rs` + `benchmark/alias.rs`
- Single-query name resolution via OR + EXISTS in `from_name_id`
- TOCTOU-safe alias validation inside write transactions
- Batched alias loading to avoid N+1 in list and report endpoints
- CLI `--alias` flag on `benchmark create` and `benchmark update`
- Generated OpenAPI spec and TypeScript types updated

Closes bencherdev#674

Made-with: Cursor
@github-actions
Copy link
Copy Markdown

🐰 Bencher Report

Branchbenchmark-alias
Testbedubuntu-22.04
Click to view all benchmark results
BenchmarkLatencyBenchmark Result
microseconds (µs)
(Result Δ%)
Upper Boundary
microseconds (µs)
(Limit %)
Adapter::Json📈 view plot
🚷 view threshold
3.94 µs
(+7.53%)Baseline: 3.66 µs
4.49 µs
(87.78%)
Adapter::Magic (JSON)📈 view plot
🚷 view threshold
4.13 µs
(+14.13%)Baseline: 3.62 µs
4.52 µs
(91.49%)
Adapter::Magic (Rust)📈 view plot
🚷 view threshold
21.01 µs
(-16.43%)Baseline: 25.14 µs
32.86 µs
(63.95%)
Adapter::Rust📈 view plot
🚷 view threshold
3.01 µs
(+7.48%)Baseline: 2.80 µs
3.22 µs
(93.57%)
Adapter::RustBench📈 view plot
🚷 view threshold
2.98 µs
(+6.67%)Baseline: 2.80 µs
3.22 µs
(92.81%)
head_version_insert/batch/10📈 view plot
🚷 view threshold
110.88 µs
(+9.91%)Baseline: 100.88 µs
117.82 µs
(94.11%)
head_version_insert/batch/100📈 view plot
🚷 view threshold
252.03 µs
(+5.56%)Baseline: 238.74 µs
263.96 µs
(95.48%)
head_version_insert/batch/255📈 view plot
🚷 view threshold
475.51 µs
(+2.56%)Baseline: 463.65 µs
498.88 µs
(95.31%)
head_version_insert/batch/50📈 view plot
🚷 view threshold
170.22 µs
(+5.15%)Baseline: 161.89 µs
182.14 µs
(93.45%)
threshold_query/join/10📈 view plot
🚷 view threshold
157.70 µs
(+8.02%)Baseline: 145.99 µs
168.85 µs
(93.40%)
threshold_query/join/20📈 view plot
🚷 view threshold
170.44 µs
(+6.08%)Baseline: 160.67 µs
187.60 µs
(90.85%)
threshold_query/join/5📈 view plot
🚷 view threshold
148.00 µs
(+7.01%)Baseline: 138.31 µs
160.91 µs
(91.97%)
threshold_query/join/50📈 view plot
🚷 view threshold
213.72 µs
(+5.86%)Baseline: 201.89 µs
231.43 µs
(92.35%)
🐰 View full continuous benchmarking report in Bencher

Copy link
Copy Markdown
Member

@epompeii epompeii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @Louisvranderick! Just took a cursory look.

Comment on lines +70 to +71
#[clap(long = "alias")]
pub aliases: Vec<BenchmarkName>,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The convention is to use the singular form for the field name (ie alias) even when it can be supplied multiple times.

Also using Option<Vec<BenchmarkName>> would be preferred to properly convey the semantics.

Comment on lines 50 to +56
pub slug: BenchmarkSlug,
pub created: DateTime,
pub modified: DateTime,
pub archived: Option<DateTime>,
/// Additional exact-match strings (the primary [`Self::name`] is always a matcher).
#[serde(default)]
pub aliases: Vec<BenchmarkName>,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conceptually, aliases should come after slug and before the timestamp fields.

Comment on lines +77 to +81
NameId::Uuid(_) | NameId::Slug(_) => schema::benchmark::table
.filter(schema::benchmark::project_id.eq(project_id))
.filter(Self::eq_name_id(name_id))
.first::<Self>(conn)
.map_err(resource_not_found_err!(Benchmark, (project_id, name_id))),
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're already matching here, it is a bit silly to then have to requery by NameId.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants