Entity: clientWeatherStation

Entity Definition

• Entity Name: clientWeatherStation

• Entity Type: Database table (join table with metadata)

• Description: Records weather station assignments for a client. A client has one default station (stored as client.defaultWeatherStationId) used for consumption normalisation across all buildings. Supplementary station assignments are stored here — each row links a weather station to a client and optionally to a specific building. A row with buildingId = null represents a client-level supplementary station; a row with a specific buildingId overrides the default for that building. A single weatherStationId may appear in multiple rows — one supplementary station can be assigned to several buildings at the same time; the composite uniqueness constraint below applies only to (clientId, buildingId), not to weatherStationId.

  Default station vs. supplementary stations: the client's default weather station is stored directly on client.defaultWeatherStationId (nullable FK). This table stores only supplementary assignments.

  Resolution logic: a building uses its specific assignment from this table if one exists; otherwise it falls back to client.defaultWeatherStationId. Otherwise no normalisation is applied.

  Because of this split, every row in clientWeatherStation is a supplementary assignment. There is no need for a role attribute distinguishing default from supplementary, since the default is never represented as a row in this table.

Data Attributes Table

Attribute Name	Description	Data Type	Default Value	Required (= Nullable)	Unique	Format	Validations	Index	Example
id	Primary key	UUID	Generated in code (app layer)	Yes	Yes	UUID v7	-	Primary Key	018ed0b3-c298-7c7a-96d5-8b36f5a7f8d2
tenantId	Tenant this record belongs to.	UUID	-	Yes	No	UUID v7	FK → tenant; must exist	name: idx_client_weather_station_tenantId, type: btree	018fa51f-fda1-79f4-8461-2cb8f1cabc10
clientId	Client this assignment belongs to	UUID	-	Yes	No	UUID v7	FK → client; must exist — see client	name: idx_client_weather_station_clientId, type: btree	018fa51f-fda1-79f4-8461-2cb8f1cabc10
weatherStationId	The assigned weather station	UUID	-	Yes	No	UUID v7	FK → weatherStation; must exist; onDelete CASCADE	name: idx_client_weather_station_weatherStationId, type: btree	018ed0b3-c298-7c7a-96d5-8b36f5a7f8d2
buildingId	Building this assignment applies to. Null means the station applies to the entire client (supplementary at client level). When set, this station overrides the client default for that building specifically.	UUID	-	No	No	UUID v7	FK → building; nullable; onDelete CASCADE. Composite unique with (clientId, buildingId) — one supplementary station per building.	name: idx_client_weather_station_clientId_buildingId, type: btree (unique, nulls distinct)	018ed0b3-c298-7c7a-96d5-8b36f5a7f8d2
createdAt	Timestamp of when the record was created. Immutable after insert.	Timestamp with time zone	now() — set in code	Yes	No	ISO 8601 — YYYY-MM-DDTHH:mm:ss.SSSZ	Cannot be null; cannot be modified after creation	-	2025-03-16T18:00:00Z
createdBy	Identifier of the actor who created the record	String	-	Yes	No	type:actor	Non-empty	-	user:018ed0b3-c298-7c7a-96d5-8b36f5a7f8d2

Discrepancy — incomplete audit block: the source Confluence page only lists createdAt and createdBy; it is missing updatedAt, deletedAt, and updatedBy, which the foundations doc (§5) requires on every persistent entity as a trailing quintet, and which every other migrated sibling entity carries in full. This is very likely an oversight on the source page (this is a join table that may genuinely never be updated/soft-deleted, which would make the omission intentional — but that isn't stated). Carried over exactly as documented rather than inventing the missing rows; recommend confirming with the author whether clientWeatherStation truly has no update/soft-delete semantics, or whether the three missing rows should be added upstream and re-migrated.

Audited fields

Recorded on created (in full) and deleted (in full) — this entity's own Data Attributes Table carries no updatedAt/updatedBy at all, so no field of an existing assignment can ever change; a re-assignment is a delete of the old row plus a create of the new one, never an update: clientId, weatherStationId, buildingId.

Excluded: none.

Every entry would carry subjectEntityType = client / subjectEntityId = clientId — buildingId (null for a client-level assignment, set for a building-level override) rides as a field on the entry rather than as a second subject.

Not registered for entityName resolution — a join row (client × weather station, optionally × building), not a named record of its own.