DB updates for Procedural Constraints

[dandelany]

Background

Now that Procedural Scheduling has been released, we are working on implementing Procedural Constraints. The workflow for using them will be very similar to scheduling goals: write a constraint in Java, compile a JAR, upload it via the Aerie UI, and add it to a plan using the same list UI that is used for eDSL constraints. Whereas procedural scheduling goals create activities on an editable plan, procedural constraints will return violations, ie. windows of time when the constraint is violated, and will not be able to edit the plan directly.

Implementing procedural goals required some changes to the database schema, to support storing them in the database and associating them with a plan:

deployment/hasura/migrations/Aerie/10_procedural_scheduling/up.sql

In particular, since multiple invocations of the same goal are now allowed in a plan spec, we had to switch from a primary key of goal_id to goal_invocation_id, representing a single invocation of a goal.

Requirements

• Define a new database schema & write a migration similar (nearly identical) to the one for procedural scheduling, to support procedural constraints
• Just like goals:
  • Multiple invocations of the same constraint will be allowed on a plan, necessitating a switch to constraint_invocation_id
  • Procedural constraints may have parameters/arguments
  • User should be able to have a mix of eDSL constraints & procedural constraints on their plan spec

Related Issues

#1571, NASA-AMMOS/aerie-ui#1478

[dandelany]

@skovati, @Mythicaeda, @AaronPlave & I met today about this - I tried to sum up our thoughts on this comment on the UI issue:

NASA-AMMOS/aerie-ui#1478 (comment)

As a result of these decisions, the database needs to implement:

• Add an "order" field to constraint run and constraint invocation tables, to keep track of constraint's position in the list
• Add a "force" flag to the endpoint which runs constraints -
  • If false, check cached table and return cached results if they exist, else run constraints
  • If true, always re-run constraints even if cached results exist

Besides this, the linked draft PR is nearly complete - the other known outstanding issue @skovati is working on is getting the migrations working/passing checks and testing migration with some real data.