-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Procedural Constraints Action/Database Support #1596
base: develop
Are you sure you want to change the base?
Conversation
Active works in progress:
|
@@ -10,7 +12,7 @@ create table merlin.constraint_run ( | |||
requested_at timestamptz not null default now(), | |||
|
|||
constraint constraint_run_key | |||
primary key (constraint_id, constraint_revision, simulation_dataset_id), | |||
primary key (constraint_invocation_id, simulation_dataset_id), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Blocking: This pkey is not sufficient. If the user decides to check constraints twice, updating the definition of a constraint between checks, they will get a pkey conflict when the action attempts to cache the output of the second definition.
(This comment is here to prevent me from not fixing this)
141cec3
to
9b55bd7
Compare
9b55bd7
to
615767e
Compare
615767e
to
770a4c8
Compare
563a1d4
to
4e556a3
Compare
- named `priority` in the DB to maintain schema parity with scheduling, and because `order` is a reserved keyword in SQL - fixes #1633
- add a column to track errors that occur when a constraint is run - replace 'constraint_run' with an association table between 'constraint_request' and 'constraint_results' - update Hasura metadata
Code Pattern now matches the one used for Procedural Constraints, with the definition stored within a Type interface Similarly, Constraint and ConstraintRecord have been merged, as they contain the exact same fields.
Include constraint invocation id in violations response
Now gets the type of the constraint, and the JAR path, in the case of procedural constraint. Changes the ConstraintRecord creation code to use column names to get values rather than depending on the column order of the SQL statement.
Class now has two types: A SuccessType and a FailureType. This allows us to know what type the value is when working with an instance. `getOrNull` has been replaced with `get` Single Constructor has been split into a Success Constructor and a Failure Constructor
The code will throw if the Optional is not present, so the wrapping is unnecessary
…ources Three implementations: 1) EDSLConstraintResult: Formerly ConstraintResult, implementation unchanged aside from adding a toJSON method. 2) DBConstraintResult: A record storing a Constraint Result that originated from the database 3) ProceduralConstraintResult: A record storing a
Changes the output of the plan constraints from a map to a list, as the keyset is only accessed for a `remove` command. Remove ConstraintRunRecord, as DBConstraintResult replaces it
…s Exception>> Refactors ConstraintsCompilationError to be an Extension If a running constraint throws an exception, that exception is now caught and put in the results map Generalizes serializeConstraintCompilationErrors to handle all Constraint Errors
ff2b995
to
4b76798
Compare
|
Description
Mirroring the database changes that were made for procedural scheduling support, this PR makes the following changes to the
constraints
sub-schema inmerlin
:invocation_id
was added toconstraint_specification
and made the new (sole) primary key. This allows for multiple "invocations" of that same constraint definition in the same spec.type
enum,uploaded_jar_id
, andparameter
schema fields were added toconstraint_definition
to support procedural constraintsdefinition
was made nullable inconstraint_definition
, since it will be null when that constraint's source code is contained in the uploaded jar.constraint_run
now holds an additional field,constraint_invocation_id
, which replaced(constraint_id, constraint_revision)
in the primary key definition. This is so we can have a constraint run for each invocation in a plan spec, which might share constraint definitions and revisions.constraint_run
also holds the "as run" arguments that were passed to the constraint during execution in a new json fieldarguments
.Verification
WIP
Documentation
Future work