Skip to content

Draft: allow for preferred events by pipeline

Alexander Pace requested to merge pipeline_preferred into master

Described in words in this issue: #216 (closed)

The basic steps are:

  • create database table with basic validation
  • create path through API to add and remove events (i'm thinking that i just add them to the same as for modifying superevents, to combine API calls)
  • create a validator or form that ingests a superevent_id and a graceid and then adds or removes the event from the table
  • add the table to the rest API and igwn_alert response
  • add log messages and igwn_alerts for new additions. I think that should come for free with the modify superevent API route.
  • make a table on the superevent landing page
  • unit tests and whatnot

I'm insistent on having GraceDB be "dumb" in terms of choosing which events are preferred by pipeline. But, GraceDB should have some logic about what events can and can't be in the table. My first cut at the logic is:

  1. elements in the pipeline_preferred table are unique based on their pipeline. so only one addition per pipeline.
  2. a superevent's preferred_event is always in the pipeline_preferred table. Changing the preferred_event will add or remove events from the pipeline_preferred table, provided that the uniqueness constraint is maintained. The new preferred_event is given priority in the
  3. Adding a new pipeline_preferred event to the table, where there is an existing event from the same pipeline removes the old event in favor of the new one. So new pipeline preferred events take priority.
  4. Removing pipeline preferred events from the table is allowed, but not in the event is current the preferred_event.
Edited by Alexander Pace

Merge request reports

Loading