@golemio/energetics 1.13.0 → 1.13.1-dev.2769672204

package/db/example/07_enapo_om_detail.sql

@@ -56,11 +56,11 @@ INSERT INTO enapo_ppas_distribution_installation (invoice_id, customer_id, place
 INSERT INTO enapo_ppas_distribution_invoice_device (device_serial_number, invoice_id, place_id, date_from, date_to,
 	"type", kind, reading_type, reading_from, reading_to, consumption, unit, meter_reading_type, gas_consumption_kwh,
 	volume_coefficient, combustion_heat, normometers_nm3) VALUES
-	('PLYN-001', 'DI-2026-001', '10101325', '2025-03-01', '2026-02-28', 'G4', 'plynoměr',
-		'řádný', 10250.0, 11930.0, 1680.0, 'm3', 'dálkový', 17750.4,
+	('PLYN-001', 'DI-2026-001', '10101325', '2025-03-01', '2026-02-28', 'G4', 'ZIZWC',
+		'STANDARD', 10250.0, 11930.0, 1680.0, 'M3', 'dálkový', 17750.4,
 		1.0043, 10.55, 1687.2),
-	('PLYN-999', 'DI-2026-001', '10101999', '2025-03-01', '2026-02-28', 'G4', 'plynoměr',
-		'řádný', 500.0, 700.0, 200.0, 'm3', 'dálkový', 2113.1,
+	('PLYN-999', 'DI-2026-001', '10101999', '2025-03-01', '2026-02-28', 'G4', 'ZIZWC',
+		'STANDARD', 500.0, 700.0, 200.0, 'M3', 'dálkový', 2113.1,
 		1.0043, 10.55, 200.9);
 
 INSERT INTO enapo_ppas_distribution_invoice_price (invoice_id, customer_id, place_id, date_from, date_to, kind,
@@ -104,7 +104,7 @@ INSERT INTO enapo_ppas_commercial_invoice_device (device_serial_number, invoice_
 	"type", kind, reading_type, reading_from, reading_to, consumption, unit, meter_reading_type, gas_consumption_kwh,
 	volume_coefficient, combustion_heat, normometers_nm3) VALUES
 	('PLYN-001', 'CI-2026-001', '10101325', '2025-03-01', '2026-02-28',
-		'G4', 'plynoměr', 'řádný', 10250.0, 11930.0, 1680.0, 'm3', 'dálkový', 17750.4,
+		'G4', 'ZIZWC', 'STANDARD', 10250.0, 11930.0, 1680.0, 'M3', 'dálkový', 17750.4,
 		1.0043, 10.55, 1687.2);
 
 INSERT INTO enapo_ppas_commercial_invoice_price (invoice_id, customer_id, place_id, date_from, date_to, kind,
@@ -132,9 +132,14 @@ INSERT INTO enapo_porsenna_devices (source, id, building_id, parent_device_id, "
 	('prague-7', '55555555-5555-5555-5555-555555555555', 2, NULL, 'main', 'electricity_meter', 'Elektroměr vrátnice',
 		'consumption', NULL, NULL, true, '859182400000000099', 'OP-200', 'EL-999', 'GIDPOR1');
 
+-- `commodity` is the normalised commodity name, NOT the raw device type: PorsennaConsumptionTransformation
+-- maps electricity_meter -> electricity, heat_meter -> heat, water_meter -> water, gasometer -> gas.
+-- `unit` comes straight from the API and is lowercase there (kwh / m3), heat included - it is not GJ.
+-- Both were verified against production 2026-08-13; this fixture previously carried the raw device type
+-- and uppercase MWH/GJ/M3, which matched neither the ingest nor the data.
 INSERT INTO enapo_porsenna_consumption (source, device_id, "var", "period", value, unit, commodity, "count") VALUES
-	('prague-7', '11111111-1111-1111-1111-111111111111', 'yearly', '2025', 12.4, 'MWH', 'electricity_meter', 365),
-	('prague-7', '22222222-2222-2222-2222-222222222222', 'yearly', '2023', 512.3, 'GJ', 'heat_meter', 365),
-	('prague-7', '22222222-2222-2222-2222-222222222222', 'yearly', '2024', 498.1, 'GJ', 'heat_meter', 366),
-	('prague-7', '33333333-3333-3333-3333-333333333333', 'yearly', '2023', 210, 'M3', 'water_meter', 365),
-	('prague-7', '55555555-5555-5555-5555-555555555555', 'yearly', '2024', 5.5, 'MWH', 'electricity_meter', 366);
+	('prague-7', '11111111-1111-1111-1111-111111111111', 'yearly', '2025', 12.4, 'kwh', 'electricity', 365),
+	('prague-7', '22222222-2222-2222-2222-222222222222', 'yearly', '2023', 512.3, 'kwh', 'heat', 365),
+	('prague-7', '22222222-2222-2222-2222-222222222222', 'yearly', '2024', 498.1, 'kwh', 'heat', 366),
+	('prague-7', '33333333-3333-3333-3333-333333333333', 'yearly', '2023', 210, 'm3', 'water', 365),
+	('prague-7', '55555555-5555-5555-5555-555555555555', 'yearly', '2024', 5.5, 'kwh', 'electricity', 366);

package/db/example/09_enapo_consumption_history.sql

@@ -0,0 +1,196 @@
+-- Fixtures for the consumption-history block of the DeD building detail endpoint
+-- (mv_enapo_om_consumption, migration 20260813090000).
+--
+-- Deliberately on its own GIDs (GIDCH1 / GIDCH2 / GIDCH3) rather than GID100, so the assertions of
+-- the existing detail tests are untouched. Every row here buys one specific assertion; the comments
+-- say which, and most of them exist because a real-data verification run found the case.
+--
+-- Daily and hourly rows are generated rather than spelled out: 31 literal INSERTs per month says
+-- nothing that `generate_series` does not, and the point of these fixtures is the aggregate.
+--
+-- Loaded after 08_ded_search.sql, which rebuilds mv_ded_building_search; the two are independent.
+-- This file refreshes mv_enapo_om_consumption at the end.
+
+INSERT INTO eno_budova (gid, zdroj, nazev, oznaceni, platnost_od) VALUES
+	('GIDCH1', 'mhmp', 'ZŠ Spotřeba', 'ZSS', '2019-01-01'),
+	('GIDCH2', 'mhmp', 'Objekt s více plynoměry', 'OVP', '2019-01-01');
+
+INSERT INTO enapo_gid_mapping (place_id, id_type, commodity, gid, is_first_gid, link_source, valid_from, valid_to) VALUES
+	('859182400000000101', 'ean', 'electricity', 'GIDCH1', true, 'mock', '2022-01-01', NULL),
+	('27ZG100Z0000CH01', 'eic', 'gas', 'GIDCH1', true, 'mock', '2022-01-01', NULL),
+	-- one physical meter behind two PPAS registrations
+	('27ZG100Z0000CH02', 'eic', 'gas', 'GIDCH2', true, 'mock', '2022-01-01', NULL),
+	-- two physical meters on one EIC
+	('27ZG100Z0000CH03', 'eic', 'gas', 'GIDCH2', true, 'mock', '2022-01-01', NULL);
+
+
+-- =================================================================================================
+-- Electricity, metered (PRE)
+-- =================================================================================================
+
+-- 2026-05: the pre-computed total AND its VT/NT parts for all 31 days. Proves the three vars are
+-- never added together (31 * 100 = 3100 kWh, not 6200): EActi_VT_NT_DaySum is the sum of the parts.
+-- Timestamps are UTC midnight, which is how PreDailyMeasurementsTransformation writes them.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number)
+SELECT '859182400000000101', 'ean', v.value, d, v.var, 'predi_input', '8110000101', 'EL-CH-1'
+FROM generate_series(timestamptz '2026-05-01 00:00:00+00', timestamptz '2026-05-31 00:00:00+00', interval '1 day') d
+CROSS JOIN (VALUES (100.0, 'EActi_VT_NT_DaySum'), (60.0, 'EActi_VT_DaySum'), (40.0, 'EActi_NT_DaySum')) AS v(value, var);
+
+-- 2026-05 again: 15-minute raw rows for the same month. These are average POWER and 4x the energy,
+-- so if they ever leaked into the aggregate the month would not stay at 3100.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number)
+SELECT '859182400000000101', 'ean', 400.0, d, 'EFwActi_VT', 'predi_input', '8110000101', 'EL-CH-1'
+FROM generate_series(timestamptz '2026-05-01 00:15:00+00', timestamptz '2026-05-02 00:00:00+00', interval '15 minutes') d;
+
+-- 2026-06 is deliberately absent: the month must come back as null, not as a zero or an error.
+
+-- 2026-07: 31 days at 200 kWh = 6200 kWh, fully covered.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number)
+SELECT '859182400000000101', 'ean', 200.0, d, 'EActi_VT_NT_DaySum', 'predi_input', '8110000101', 'EL-CH-1'
+FROM generate_series(timestamptz '2026-07-01 00:00:00+00', timestamptz '2026-07-31 00:00:00+00', interval '1 day') d;
+
+-- 2026-04: only the VT and NT parts, no pre-computed total. Exercises the COALESCE(total, vt + nt)
+-- fallback, which real data never reaches (EActi_VT_NT_DaySum is always present in production), so
+-- without this fixture that branch would ship untested. 30 * (50 + 25) = 2250 kWh.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number)
+SELECT '859182400000000101', 'ean', v.value, d, v.var, 'predi_input', '8110000101', 'EL-CH-1'
+FROM generate_series(timestamptz '2026-04-01 00:00:00+00', timestamptz '2026-04-30 00:00:00+00', interval '1 day') d
+CROSS JOIN (VALUES (50.0, 'EActi_VT_DaySum'), (25.0, 'EActi_NT_DaySum')) AS v(value, var);
+
+-- An electricity row stored with id_type = 'eic'. Production contains this, so the join must ignore
+-- id_type entirely; if anyone "fixes" the join by matching on it, 2026-03 disappears.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number)
+SELECT '859182400000000101', 'eic', 10.0, d, 'EActi_VT_NT_DaySum', 'predi_input', '8110000101', 'EL-CH-1'
+FROM generate_series(timestamptz '2026-03-01 00:00:00+00', timestamptz '2026-03-31 00:00:00+00', interval '1 day') d;
+
+
+-- =================================================================================================
+-- Gas, metered (PPAS InternetAVE)
+-- =================================================================================================
+
+-- 27ZG100Z0000CH01, 2026-07: corediff is the primary value -> 3 * 50 = 150 m3, over 3 distinct days.
+-- core2 is present and non-zero but must NOT win.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
+	('27ZG100Z0000CH01', 'eic', 50.0, '2026-07-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 50.0, '2026-07-02 01:00:00+02', 'corediff', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 50.0, '2026-07-03 01:00:00+02', 'corediff', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 55.0, '2026-07-01 01:00:00+02', 'core2', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 55.0, '2026-07-02 01:00:00+02', 'core2', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 55.0, '2026-07-03 01:00:00+02', 'core2', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	-- the cumulative meter state: present, and deliberately unused (max - min across an EIC's
+	-- registrations is the distance between unrelated counters, so it is not a fallback)
+	('27ZG100Z0000CH01', 'eic', 900000.0, '2026-07-01 01:00:00+02', 'core', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 900150.0, '2026-07-03 01:00:00+02', 'core', 'ppas_ave_api', '9900001', 'GAS-CH-1');
+
+-- 2026-06: corediff has data, core2 is present but ALL ZERO. 0 is not NULL, so a bare COALESCE
+-- would return a flat-zero Nm3 series here - exactly what production does for some EICs. The
+-- expected result is 120 m3 from corediff.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
+	('27ZG100Z0000CH01', 'eic', 60.0, '2026-06-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 60.0, '2026-06-02 01:00:00+02', 'corediff', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 0.0, '2026-06-01 01:00:00+02', 'core2', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 0.0, '2026-06-02 01:00:00+02', 'core2', 'ppas_ave_api', '9900001', 'GAS-CH-1');
+
+-- 2026-05: only core2. The series falls back to Nm3 for this month, which means one point can change
+-- unit mid-window and therefore appears as two series - honest, and why `unit` is part of the key.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
+	('27ZG100Z0000CH01', 'eic', 30.0, '2026-05-01 01:00:00+02', 'core2', 'ppas_ave_api', '9900001', 'GAS-CH-1'),
+	('27ZG100Z0000CH01', 'eic', 30.0, '2026-05-02 01:00:00+02', 'core2', 'ppas_ave_api', '9900001', 'GAS-CH-1');
+
+-- 27ZG100Z0000CH02, 2026-07: TWO place_ids, ONE meter serial - two live registrations of the same
+-- physical meter, both reporting the same intervals. Expected 100 m3, NOT 200: the aggregate picks
+-- one registration per serial (the most recently reporting one, here 9900012).
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
+	('27ZG100Z0000CH02', 'eic', 100.0, '2026-07-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900011', 'GAS-CH-DUP'),
+	('27ZG100Z0000CH02', 'eic', 100.0, '2026-07-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900012', 'GAS-CH-DUP');
+
+-- 27ZG100Z0000CH03, 2026-07: TWO place_ids, TWO serials - genuinely two meters on one delivery
+-- point. Expected 200 m3: deltas from distinct meters do add up.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
+	('27ZG100Z0000CH03', 'eic', 100.0, '2026-07-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900021', 'GAS-CH-A'),
+	('27ZG100Z0000CH03', 'eic', 100.0, '2026-07-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900022', 'GAS-CH-B');
+
+
+-- =================================================================================================
+-- Gas, invoices (PPAS distribution) for 27ZG100Z0000CH01
+-- =================================================================================================
+
+INSERT INTO enapo_ppas_distribution_invoice (id, preceding_id, customer_id, customer_name,
+	facts_doc_date, facts_to_pay_amount, facts_currency, is_canceled) VALUES
+	('DI-CH-001', NULL, 'CUST-CH', 'Hlavní město Praha', '2026-07-10', 5000.00, 'CZK', false),
+	-- A second, later invoice repeating DI-CH-001's device rows verbatim, with NO preceding_id link.
+	-- Production has these. Deduplicating on invoice lineage alone would count 2026-06 twice.
+	('DI-CH-002', NULL, 'CUST-CH', 'Hlavní město Praha', '2026-07-20', 5000.00, 'CZK', false);
+
+INSERT INTO enapo_ppas_distribution_installation (invoice_id, customer_id, place_id, eic, tdd_class) VALUES
+	('DI-CH-001', 'CUST-CH', '9900001', '27ZG100Z0000CH01', 'DOM4'),
+	('DI-CH-002', 'CUST-CH', '9900001', '27ZG100Z0000CH01', 'DOM4');
+
+INSERT INTO enapo_ppas_distribution_invoice_device (device_serial_number, invoice_id, place_id, date_from, date_to,
+	"type", kind, reading_type, consumption, unit, gas_consumption_kwh, volume_coefficient, combustion_heat,
+	normometers_nm3) VALUES
+	-- The kept row: ZIZWC is the broad volume kind. One whole month, so no pro-rata and
+	-- is_estimated stays false. 500 m3 -> 5275 kWh at 10.55 kWh/m3.
+	('GAS-CH-1', 'DI-CH-001', '9900001', '2026-06-01', '2026-06-30', 'G4', 'ZIZWC', 'STANDARD',
+		500.0, 'M3', 5275.0, 1.0043, 10.55, 500.0),
+	-- ZSATN3 is the SAME gas expressed in Nm3 (production has identical totals across the two).
+	-- It must be excluded, or June doubles.
+	('GAS-CH-1', 'DI-CH-001', '9900001', '2026-06-01', '2026-06-30', 'G4', 'ZSATN3', 'STANDARD',
+		500.0, 'NM3', 0.0, 1.0043, 10.55, 500.0),
+	-- A CORRECTION sibling. Additive in production but signed only in gas_consumption_kwh, so it is
+	-- excluded in v1; if it were summed naively June would gain 40 m3 and lose 422 kWh.
+	('GAS-CH-1', 'DI-CH-001', '9900001', '2026-06-01', '2026-06-30', 'G4', 'ZIZWC', 'CORRECTION',
+		40.0, 'M3', -422.0, 1.0043, 10.55, 40.0),
+	-- The byte-identical duplicate on the later invoice. June must stay at 500 m3.
+	('GAS-CH-1', 'DI-CH-002', '9900001', '2026-06-01', '2026-06-30', 'G4', 'ZIZWC', 'STANDARD',
+		500.0, 'M3', 5275.0, 1.0043, 10.55, 500.0),
+	-- An inverted period. generate_series would produce nothing for it anyway, but the explicit
+	-- guard keeps it from silently disappearing into a NULL share.
+	('GAS-CH-1', 'DI-CH-001', '9900001', '2026-05-31', '2026-05-01', 'G4', 'ZIZWC', 'STANDARD',
+		99.0, 'M3', 999.0, 1.0043, 10.55, 99.0),
+	-- combustion_heat = 0 means "not supplied", not a real coefficient: value_kwh must be null here,
+	-- not 0, because 0 would be charted as a real reading. April, so it does not disturb June.
+	('GAS-CH-1', 'DI-CH-001', '9900001', '2026-04-01', '2026-04-30', 'G4', 'ZIZWC', 'STANDARD',
+		300.0, 'M3', 0.0, 0.0, 0.0, 300.0);
+
+
+-- =================================================================================================
+-- Porsenna: yearly only, on its own GID namespace (porsenna gid is not an ENO gid - 0 of 32 match in
+-- production - so these points are servable by GID but invisible to the DeD map)
+-- =================================================================================================
+
+INSERT INTO enapo_porsenna_buildings (source, id, name, street, house_number, city, postcode, gid) VALUES
+	('prague-7', 90, 'Objekt s teplem', 'Tepelná', '9', 'Praha 7', '17000', 'GIDCH3');
+
+INSERT INTO enapo_porsenna_devices (source, id, building_id, parent_device_id, "level", "type", name,
+	measurement_target, disabled_at, show_in_output, identifier, supply_point_number, meter_number) VALUES
+	('prague-7', '9a000000-0000-0000-0000-000000000001', 90, NULL, 'main', 'heat_meter',
+		'Předávací stanice', 'budova', NULL, true, '10109901', 'OP-901', 'TEP-901'),
+	('prague-7', '9a000000-0000-0000-0000-000000000002', 90, NULL, 'main', 'water_meter',
+		'Vodoměr', 'budova', NULL, true, '10109902', 'OP-902', 'VOD-902'),
+	-- TWO devices sharing one identifier. Porsenna heat/water identifiers are labels ("R1"), not the
+	-- numeric OM the column comment suggests, so they are not unique within a building - production
+	-- has exactly this and it broke the unique index on the first real refresh.
+	('prague-7', '9a000000-0000-0000-0000-000000000003', 90, NULL, 'main', 'water_meter',
+		'Vodoměr R1 přední', 'budova', NULL, true, 'R1', 'OP-903', 'VOD-903'),
+	('prague-7', '9a000000-0000-0000-0000-000000000004', 90, NULL, 'main', 'water_meter',
+		'Vodoměr R1 zadní', 'budova', NULL, true, 'R1', 'OP-904', 'VOD-904');
+
+-- Yearly rows only, bare YYYY periods, lowercase units, commodity normalised to the commodity name
+-- (not the device type) - all four verified against production. Heat is kwh, not GJ.
+-- The 2025 water row is a real 0 with a full year of coverage: zero consumption is data, and must
+-- come back as 0 rather than being dropped or turned into null.
+INSERT INTO enapo_porsenna_consumption (source, device_id, "var", "period", value, unit, commodity, "count") VALUES
+	('prague-7', '9a000000-0000-0000-0000-000000000001', 'yearly', '2023', 41000.5, 'kwh', 'heat', 365),
+	('prague-7', '9a000000-0000-0000-0000-000000000001', 'yearly', '2024', 39500.0, 'kwh', 'heat', 366),
+	('prague-7', '9a000000-0000-0000-0000-000000000002', 'yearly', '2025', 0.0, 'm3', 'water', 365),
+	-- The two devices sharing identifier 'R1', both reporting 2022: they collapse onto one key of the
+	-- unique index, so the view has to aggregate them (12 + 8 = 20 m3) rather than emit two rows.
+	('prague-7', '9a000000-0000-0000-0000-000000000003', 'yearly', '2022', 12.0, 'm3', 'water', 365),
+	('prague-7', '9a000000-0000-0000-0000-000000000004', 'yearly', '2022', 8.0, 'm3', 'water', 365),
+	-- An unparsable period: skipped by f_enapo_safe_period rather than aborting the whole refresh.
+	('prague-7', '9a000000-0000-0000-0000-000000000002', 'monthly', '2025-13', 5.0, 'm3', 'water', 30);
+
+
+REFRESH MATERIALIZED VIEW mv_ded_building_search;
+REFRESH MATERIALIZED VIEW mv_enapo_om_consumption;

package/db/migrations/postgresql/20260813090000-enapo-consumption-history.js

@@ -0,0 +1,53 @@
+'use strict';
+
+var dbm;
+var type;
+var seed;
+var fs = require('fs');
+var path = require('path');
+var Promise;
+
+/**
+  * We receive the dbmigrate dependency from dbmigrate initially.
+  * This enables us to not have to rely on NODE_PATH.
+  */
+exports.setup = function(options, seedLink) {
+  dbm = options.dbmigrate;
+  type = dbm.dataType;
+  seed = seedLink;
+  Promise = options.Promise;
+};
+
+exports.up = function(db) {
+  var filePath = path.join(__dirname, 'sqls', '20260813090000-enapo-consumption-history-up.sql');
+  return new Promise( function( resolve, reject ) {
+    fs.readFile(filePath, {encoding: 'utf-8'}, function(err,data){
+      if (err) return reject(err);
+      console.log('received data: ' + data);
+
+      resolve(data);
+    });
+  })
+  .then(function(data) {
+    return db.runSql(data);
+  });
+};
+
+exports.down = function(db) {
+  var filePath = path.join(__dirname, 'sqls', '20260813090000-enapo-consumption-history-down.sql');
+  return new Promise( function( resolve, reject ) {
+    fs.readFile(filePath, {encoding: 'utf-8'}, function(err,data){
+      if (err) return reject(err);
+      console.log('received data: ' + data);
+
+      resolve(data);
+    });
+  })
+  .then(function(data) {
+    return db.runSql(data);
+  });
+};
+
+exports._meta = {
+  "version": 1
+};

package/db/migrations/postgresql/sqls/20260813090000-enapo-consumption-history-down.sql

@@ -0,0 +1,12 @@
+DROP MATERIALIZED VIEW IF EXISTS mv_enapo_om_consumption;
+
+DROP FUNCTION IF EXISTS f_enapo_safe_period(text, text);
+
+DROP INDEX IF EXISTS enapo_measurements_source_var_ts_idx;
+
+DROP INDEX IF EXISTS enapo_ppas_distribution_invoice_preceding_id_idx;
+DROP INDEX IF EXISTS enapo_ppas_commercial_invoice_preceding_id_idx;
+
+-- Restore the original (misleading) wording so the down migration is a true inverse.
+COMMENT ON COLUMN enapo_porsenna_consumption.commodity IS
+	'Denormalised from enapo_porsenna_devices.type for fast filtered reads.';