Fixes an issue discovered by @parkerabercrombie during database migration while upgrading from Aerie 2.11.2 to 3.1.0:
While on 2.11.2, there was a plan that had some scheduling goals which were run, and produced scheduling goal analysis rows in the database.
Some of these goals were removed from the plan after the scheduling run, which caused the scheduling analysis rows to refer to a goal_id which was no longer in the plan spec (didn't cause any issues yet).
The up.sql migration 10 assigns goal_invocation_ids to all goal invocations in the plan spec, and propagates these IDs to the corresponding entries in the goal analysis tables.
This process expected that all analysis rows would refer to goals that still existed in the plan spec, but since some goals were removed from the spec, the associated analysis rows were assigned null as their goal_invocation_id, which is not legal to be used as part of a primary key
This caused the migration to fail when trying to set the primary key to include this column
This PR fixes the issue by assigning a "dummy value" to any goal analysis rows which would have suffered from this problem - instead of setting the goal_invocation_id to null, we (somewhat arbitrarily) set it to the negative of the goal id which instantiated it. This could have been any valid integer, but we decided to use this as the value since it gives us a bit more information about where the analysis came from.
Fixes an issue discovered by @parkerabercrombie during database migration while upgrading from Aerie
2.11.2to3.1.0:2.11.2, there was a plan that had some scheduling goals which were run, and produced scheduling goal analysis rows in the database.goal_idwhich was no longer in the plan spec (didn't cause any issues yet).up.sqlmigration10assignsgoal_invocation_ids to all goal invocations in the plan spec, and propagates these IDs to the corresponding entries in the goal analysis tables.nullas theirgoal_invocation_id, which is not legal to be used as part of a primary keyThis PR fixes the issue by assigning a "dummy value" to any goal analysis rows which would have suffered from this problem - instead of setting the
goal_invocation_idto null, we (somewhat arbitrarily) set it to the negative of the goal id which instantiated it. This could have been any valid integer, but we decided to use this as the value since it gives us a bit more information about where the analysis came from.(summarized by @dandelany )