BDMS-221-225: New measuring_point_history model#244
Conversation
The current schema lacks a way to track the authoritative measuring point height over time. Created a new model, `measuring_point_history`, to store the official measuring point and description for a Thing. This table serves as a specialized historical log that tracks the measuring point over time.
A Thing may have multiple measuring points over time. As such, the `Thing` model requires a relationship to the new `measuring_point_history` model. A new One-To-Many relationship named `measuring_points` was added to the `Thing` model.
It would be useful to track the reason for updating the measuring point. Create new `reason` field in the `measuring_point_history` model.
…chemas # Conflicts: # db/thing.py
There was a problem hiding this comment.
since this model only pertains to the thing model I don't think that it needs to go into its own file. It can go into db/thing.py
There was a problem hiding this comment.
Happy to do this. Just curious, how are we deciding which models get their own files? When I'm looking for info about a table/model, I'm expecting it to be listed in the db directory.
There was a problem hiding this comment.
I don't know if we have a standard, but when making a new model I put it into an existing file if it only pertains to other models in that file (e.g. WellPurpose and WellCasingMaterial). [Now that I think of it, I don't know if I've created a standalone model, but it makes sense for me to have the polymorphic models be in their own files for ease of understanding.]
There was a problem hiding this comment.
@jirhiker I merged this so I can use develop off of it - where the table is defined in the codebase won't affect how it's used in the schemas/tests. If you think it should be in the db/thing.py file I can move it there easily.
The `back_populates` parameter in the relationship section was updated to match the relationship name in the `THing` model. The `mp_description` field was renamed `measuring_point_description` for clarity.
2 participants
Why
This PR addresses the following problem / context:
How
Implementation summary - the following was changed / added / removed:
measuring_point_history, to store the official measuring point and description for a Thing.measuring_pointswas added to theThingmodel. This addresses the fact that a Thing may have multiple measuring points over time.Notes
Any special considerations, workarounds, or follow-up work to note?