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