Add allegations table
#1131
Add allegations table
#1131
Conversation
| @@ -705,6 +705,28 @@ class Incident(BaseModel, TrackUpdates): | |||
| ) | |||
|
|
|||
|
|
|||
| class Allegation(BaseModel, TrackUpdates): | |||
There was a problem hiding this comment.
For some reason, I cannot get alembic to generate a migration for this table addition. Is there anything that looks out of place, @sea-kelp?
There was a problem hiding this comment.
I tried a number of things with the LPL OO alembic but couldn't get it to generate the revision. I was however able to cherry pick the commits (613489b..f2977e4) into our OpenOversight repo and generate the revision there. I'm wondering if there's maybe a change that we haven't ported over yet that's causing the issue?
OrcaCollective@cadea71
Obviously, our models might be slightly different from yours so I wouldn't recommend directly using this generated migration
There was a problem hiding this comment.
I remember seeing some comments that each individual models needs to be imported into Alembic's env.py file. I'll take a look at the Orca one and see what the differences are.
There was a problem hiding this comment.
It's super hacky, but I added the table without it creating a migration and then removed the table and it created a migration. I'm just going to reverse the code on upgrade and downgrade, and take that result. I'm not super happy with how it ended up working, but I'll take it at this point.
There was a problem hiding this comment.
If I downgrade and then upgrade the flask db command, it will error since the table will already be created when the application starts out.
I then continually used the flask db downgrade command and we get errors for other downgrades as well. I think this means we are consistent, but there are certainly some difficulties between the ORM and flask to maybe look into at some point.
There was a problem hiding this comment.
At a higher-level, I think we were discussing having multiple incident-types (lawsuits, internal investigations), each of which would have different types of additional fields.
I was thinking that allegations would belong to an internal investigation-type incident but wouldn't really apply to lawsuits, though I could see an argument for lawsuit causes of action as allegations.
| @@ -705,6 +705,28 @@ class Incident(BaseModel, TrackUpdates): | |||
| ) | |||
|
|
|||
|
|
|||
| class Allegation(BaseModel, TrackUpdates): | |||
There was a problem hiding this comment.
I tried a number of things with the LPL OO alembic but couldn't get it to generate the revision. I was however able to cherry pick the commits (613489b..f2977e4) into our OpenOversight repo and generate the revision there. I'm wondering if there's maybe a change that we haven't ported over yet that's causing the issue?
OrcaCollective@cadea71
Obviously, our models might be slightly different from yours so I wouldn't recommend directly using this generated migration
|
Would you prefer to have a quick video conversation about this at some point, @sea-kelp? |
michplunkett
requested review from
b-meson,
AetherUnbound,
abandoned-prototype and
sea-kelp
Fixes issue
#983
This PR is the first step for the ticket.
Description of Changes
Adding allegations table.
Tests and Linting
developbranch.pytestpasses on my local development environment.pre-commitpasses on my local development environment.