Skip to content

refactor: align ScannerDbContext with sibling *Context naming - #379

Merged
hokiepokedad2 merged 1 commit into
mainfrom
refactor/240-scanner-context-naming
Aug 5, 2026
Merged

refactor: align ScannerDbContext with sibling *Context naming#379
hokiepokedad2 merged 1 commit into
mainfrom
refactor/240-scanner-context-naming

Conversation

@hokiepokedad2

Copy link
Copy Markdown
Contributor

Closes #240.

What

Renames ScannerDbContextScannerContext so all three DbContext subclasses share one convention:

Before After
PoracleContext PoracleContext
PoracleWebContext PoracleWebContext
ScannerDbContext ScannerContext

A bit of history: #232 renamed RdmScannerContextScannerDbContext and is where the odd-one-out Db infix came from. This restores the pattern that rename broke.

Changed

  • Data/Pgan.PoracleWebNet.Data.Scanner/ScannerDbContext.csScannerContext.cs (class + DbContextOptions<> type argument). Done with git mv, so the rename is detected at 83% similarity and git blame follows through.
  • Core/Pgan.PoracleWebNet.Core.Services/ScannerService.cs — ctor parameter and _context field type.
  • Applications/Pgan.PoracleWebNet.Api/Configuration/ServiceCollectionExtensions.cs:104AddDbContext<ScannerContext> in the optional-registration block.
  • docs/architecture/database.md, CLAUDE.md — the two doc mentions.
  • CHANGELOG.md — entry under Unreleased → Changed.

Two corrections to the issue's suggested-fix list

  • docs/architecture/backend.md needs no change — it discusses ScannerService / ScannerGymEntity but never names the context type.
  • CLAUDE.md's file-paths table row points at the directory Data/Pgan.PoracleWebNet.Data.Scanner/, not the class, so it stays as-is.

No functional change

  • IScannerService is untouched — DI consumers resolve the interface.
  • The ConnectionStrings:ScannerDb config key is unchanged, so self-hosters need to do nothing.
  • No EF migrations involved: this context is read-only against Golbat's DB and is never migrated by PoracleWeb.
  • No wire contract, no namespace or project rename (Pgan.PoracleWebNet.Data.Scanner stays).

Verification

  • grep -rni scannerdbcontext across the repo returns only the two historical CHANGELOG.md lines (this entry and Rename Rdm* scanner types to generic Scanner*; use Golbat in examples #232's), which are correctly left alone.
  • No inbound links anywhere in docs/ to the renamed heading's old anchor (#scannerdbcontext-optional).
  • dotnet build — 0 errors, warning count unchanged from main.
  • dotnet test — 1441/1441 passing. ScannerControllerTests mocks IScannerService, so no test needed updating.
  • dotnet format --verify-no-changes on the three changed C# files — clean.
  • Frontend ESLint/Prettier not applicable: they cover ClientApp/src/**/*.{ts,html,scss} and this diff touches no frontend file.

Rename ScannerDbContext -> ScannerContext so all three DbContext
subclasses share one convention (PoracleContext, PoracleWebContext,
ScannerContext). #232 had renamed RdmScannerContext -> ScannerDbContext
and introduced the odd-one-out Db infix; this restores the pattern.

Touches the class and its file, the DbContextOptions<> type argument,
the ScannerService ctor parameter and field, the AddDbContext<>
registration, and the two doc mentions.

No functional change: IScannerService is unchanged, the optional
ConnectionStrings:ScannerDb key is unchanged, and no EF migrations are
involved (the scanner DB is read-only and never migrated by PoracleWeb).
@hokiepokedad2
hokiepokedad2 force-pushed the refactor/240-scanner-context-naming branch from 003fe70 to 42c26cb Compare August 5, 2026 13:59
@hokiepokedad2
hokiepokedad2 merged commit 26d2a82 into main Aug 5, 2026
8 checks passed
@hokiepokedad2
hokiepokedad2 deleted the refactor/240-scanner-context-naming branch August 5, 2026 14:02
hokiepokedad2 added a commit that referenced this pull request Aug 5, 2026
The v2.12.0 release cut failed at "Enable auto-merge":

  X Cannot use `-d` or `--delete-branch` when merge queue enabled

`main` gained a merge queue in #378/#379, and gh rejects the flag outright
rather than ignoring it, so the step exited 1 and the whole workflow failed. The
changelog PR itself was created and approved fine -- only the arming failed.

The flag was redundant regardless: peter-evans/create-pull-request above already
sets `delete-branch: true`, which removes the branch once the PR closes.

--squash is kept even though the queue now dictates the merge strategy (gh warns
about it) so the intent still reads correctly if the queue is ever removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

refactor: align ScannerDbContext with sibling *Context naming

1 participant