Skip to content
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

Issue #278 - Refactor Database #281

Merged
merged 14 commits into from
Jul 8, 2023
Merged

Issue #278 - Refactor Database #281

merged 14 commits into from
Jul 8, 2023

Conversation

DMalone87
Copy link
Collaborator

Makes a number of adjustments to the Index database in order to bring it into alignment with the NPDC Incident Model.

  • Adds a Suspect model that sits between Officers and Incidents. This takes over for the Accusation table.
  • Makes Source a parent of Incident rather than the opposite. Also adds a SourceDetails table to Incidents.
  • Adds Many to Many Relationships and association tables.
  • Slightly adapts the front end to the new models.

Some things that are not part of this PR that need to be taken care of:

  • Current changes will break the scrapers.
  • UI needs to be revamped to match the new model properties.
  • DB Seeds need to be updated.

DB Seeds update will be a fast follow.

Darrell Malone added 3 commits June 5, 2023 00:58
First step of the refactor is to separate the Officer table from the version that is a child of the incident table. We'll set up a standalone officer and agency table where we'll store records related to known officers and law enforcement agencies. The old officer table, now called Suspects will store information about those officers suspected of committing a crime against the public. The suspect table will be connected to officers via the accusation table.
 - Remove source from other models
 - Remove SourceMixin
Tags and Agencies linked to Incidents
Suspects and Agencies linked to officers
Style changes.
db.Column('earliest_employment', db.Text),
db.Column('latest_employment', db.Text),
db.Column('badge_number', db.Text),
db.Column('unit', db.Text),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just thinking about this - should units be a separate table which relates to an agency? This would help ensure that the unit names would be consistent across relationships which would make identifying problematic units more consistent.

Darrell Malone added 3 commits June 27, 2023 11:15
id = db.Column(db.Integer, primary_key=True) # officer id
incident_id = db.Column(db.Integer, db.ForeignKey("incident.id"))
first_name = db.Column(db.Text)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like first_name, last_name, race, ethnicity, gender, and date_of_birth could be pulled into a table called individual which officer and victim can both reference. This would allow for mapping of situations where an officer later became a victim.

perpetrator probably shouldn't have a reference to the individual table since it's providing information that would be used to identify suspected officers.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure we need that. The goal of the victim table is just to get demographic data, not to identify the victim as an individual. I want to avoid having any sort of database of victims identities.

@DMalone87
Copy link
Collaborator Author

Gonna wave this through with the front end fails. The visualization snapshot is a little flakey and it looks like prettier needs an update.

@DMalone87 DMalone87 merged commit f3320f7 into main Jul 8, 2023
3 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants