BDMS 389 inspired: status history refactor for wells#299
Closed
jacob-a-brown wants to merge 7 commits into
Closed
Conversation
this will allow the refactor from fields to the status history since these statuses can change for a well over time
…us history table these statuses are changeable, so they should be in the status history table rather than as standalone fields in the thing table
this is a status of the well not a well purpose
Codecov Report✅ All modified and coverable lines are covered by tests.
|
jirhiker
approved these changes
Dec 15, 2025
jirhiker
left a comment
jirhiker
left a comment
Member
There was a problem hiding this comment.
looks good. seems like the project structure and style is starting to settle into place
Contributor
Author
|
Should we close this PR since it is now in |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
This PR addresses the following problem / context:
thingtable had a field to storeis_suitable_for_datalogger, but no way to store if it is open. After multiple discussions we came to the conclusion that both suitability for a datalogger at a well, as well as if it is open, are actually statuses since they are mutable. They can change over time. Because of this, those two pieces of information should be stored in thestatus_historytablewell_purposetable. This includes the legacyOpen, unequipped well. This is a status to indicate if a well is open or not, so should be recorded in thestatus_historytable and not thewell_purposetable.How
Implementation summary - the following was changed / added / removed:
is_suitable_for_dataloggerfrom theThingmodelstatus_typeDatalogger Suitability Statusto the lexicon, as well as thestatus_valuesDatalogger can be installedandDatalogger cannot be installedas the possible valuesstatus_typeOpen Statusto the lexicon, as well as thestatus_valuesOpenandClosedas possible valuesstatus_historytable forDatalogger Suitability Status.Open, unequipped wellthen a record is made in thestatus_historytable wherestatus_type="Open Status"andstatus_value="Open". There is no way to determine if a well is closed, though.Notes
Any special considerations, workarounds, or follow-up work to note?
stagingI'll merge withwell-inventory-csvand make requisite updates.