avoid inserting duplicate feature_amounts_per_planning_unit rows over and over [MRXN23-609]

[hotzevzl]

https://vizzuality.atlassian.net/browse/MRXN23-609

This is only a fix for the bug. I recommend to add a migration that fixes existing duplicated data as a separate PR, to keep things manageable and fast-track this fix (if approved) to production.

There are no tests with this fix. It's going to be complicated to test this exhaustively within a limited development effort.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
marxan	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 19, 2024 7:03pm

[hotzevzl]

the banality of evil... 🙄

geoprocessing-production=> select count(*) from (select distinct project_pu_id, count(*) from features_data where feature_id = 'e334efba-97f6-43de-bd6b-f08950e4af0d' group by project_pu_id) a;
 count
-------
 14163
(1 row)

and

geoprocessing-production=> select count(*) from feature_amounts_per_planning_unit where feature_id = 'e334efba-97f6-43de-bd6b-f08950e4af0d';
 count
--------
 119163
(1 row)

$$119163 = \sum_{1}^{14}1000*n + 14163$$

Another feature from the project we were using to triage this:

geoprocessing-production=> select count(*) from feature_amounts_per_planning_unit where feature_id = '30b39d9e-ba84-4188-9721-a50bb1458ae0';
 count
-------
 54266
(1 row)

geoprocessing-production=> select count(*) from features_data where feature_id = '30b39d9e-ba84-4188-9721-a50bb1458ae0';
 count
-------
  9266
(1 row)

$$54266 = \sum_{1}^{9}1000*n + 9266$$

I can run more exhaustive checks on Monday, but my bet is on this 😃