Infra device placement parity: real site/building FKs so infra behaves like miners
- Dominant language
- Go
- Stars
- 55
- Forks
- 16
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 87
Description
## Summary
Give `infrastructure_device` real `site_id` / `building_id` foreign keys — matching the placement model of `device` (miners) — instead of the current mandatory `site_id` + free-form `building_name` string.
## Motivation
Surfaced while planning #745 (Import/Export Site Map CSV). Infra devices currently model placement asymmetrically from miners:
- `infrastructure_device.site_id` is `NOT NULL` (a fan must always belong to a site — there's no "unassigned" bucket).
- `building_name` is a **free-form `VARCHAR` string**, not a foreign key to `building`. It isn't validated against the buildings table and can drift from real building names.
- There is no rack concept for infra (fine, expected).
Because of this, the #745 CSV importer had to make infra a special case:
- Infra rows can update placement (site + building) but the uniform **"omission = remove"** policy that applies to sites/buildings/racks/miners **can't apply to infra** — the only removable attribute is `building_name` (site can't be nulled, device can't be deleted in v1), which isn't a meaningful destructive operation. So infra is **exempt** from omission-removal in #745 v1.
## Proposal
- Add `building_id BIGINT NULL` FK to `infrastructure_device` (composite `(building_id, org_id)` → `building`, consistent with `device`).
- Decide whether `site_id` should become nullable so a fan can be genuinely "unassigned" like a miner, or stay mandatory (needs product input — is a site-less fan meaningful?).
- Migrate existing `building_name` values → resolve to `building_id` where a matching building exists under the site; keep `building_name` as a transitional/denormalized display field or drop it.
- Update the infra service/handlers, proto, and client pickers to use the FK.
## Payoff
Once infra placement matches miners, the #745 importer can **treat infra identically to the other sections** — including the uniform omission-removal policy — and drop the v1 exemption (decision #4 / "Follow-ups" in the #745 plan).
## References
- Plan: `docs/plans/2026-07-14-745-import-export-site-map-csv-plan.md`
- Parent: #745
- Infra foundation: #724
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Contributor guide
Research direction
Start with the infrastructure_device schema and the existing device placement model, then read docs/plans/2026-07-14-745-import-export-site-map-csv-plan.md and the infra foundation from #724. Trace the infra service/handlers, proto, and client pickers that use site and building placement. Done requires a decided site-nullability policy, migrated building references, and consistent FK-based behavior across those surfaces.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend-api-design, databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100