* when collecting job events by creation time
it is possible to miss events that were created
at one point, but actually committed to the db
much later.
* since events' modified time is set when they are
committed to the db, we shouldn't miss any job events
* selecting job events by modified time wasn't possible
beforehand because we didn't have an index for
jobevent's modified field
Changes in old unpartitioned cleanup logic:
* Manually cascade delete events related to job(s)
(new partitions cleanup logic) For each event type:
* Get the event partitions that are within the cleanup date range
* Get a list of jobs to delete that are in the cutoff range.
* Jobs that are running, pending, or waiting in the job list are special.
* Use the special list to further filter the partition drop list.
* Drop partitions
* delete jobs
* when tests create a UnifiedJob and JobEvent,
the two need to have the same value for job creation time
* some view validation was skipped due to `model` being
a property in some cases now
we don't need this code at all anymore - the bigint migration is long
gone, and anybody upgrading to this version of AWX has already
migrated their data
keep pre-upgrade events in an old table (instead of a partition)
- instead of creating a default partition, keep all events in special
"unpartitioned" tables
- track these tables via distinct proxy=true models
- when generating the queryset for a UnifiedJob's events, look at the
creation date of the job; if it's before the date of the migration,
query on the old unpartitioned table, otherwise use the more modern table
that provides auto-partitioning
* if we use the actual old job events table
and make tweaks to its schema
namely, dropping the pkey constraint,
then when we go to migrate the old job events
we will be forcing postgres to do a sequential scan
on the old table, which effectively causes the migration to hang
events that existed *prior* to the partition migration will have
`job_created=1970-01-01` auto-applied at migration time; as such,
queries for these events e.g., /api/v2/job/N/job_events/
use 1970-01-01 in related event searche
events created *after* the partition migration (net-new playbook runs
will have `job_created` values that *exactly match* the related
`UnifiedJob.created` field.
* raw sql commands were in migration to partition table
* .. just needed to add FakeAddField entries for the new
job_created field added to each job event model
* .. and also needed to actually list the new field on the model classes
- each job event table has a different name for the
fk referencing the unified job id
- create a mapping so that we get the col name correct
for each table
