Expose House (and others) over API #29
Conversation
|
Seems like this requires a lot of knowledge about serialization. |
Allows us to serialize House from DB, and at least C / R it from database. Also has conditional logic applied so that if property_type == "OT" (Other), then other_property_type must be specified, along with additional field checks.
|
In order for this to work, we probably will need another Serializer for HouseInformation. This can be used as an optional parameter passed with the House one, or standalone on a different path ( Something of the sorts. For now, we have it at least Authenticated, and need to have a Permission that is AuthenticatedAndOwnerOrAdmin or something like that. |
|
We need to be able to:
Maybe we don't even need to implement DELETE. Ideally, we keep the records, so that we can map changes to the environment / physical bathouse. We want to probably do this by nesting ViewSets [1] [2]. This then extends to physical features, and we can then start mocking out what Flightplan expects. |
We want to model a ManyToOne relationship (there are many observations for one house, for example), which isn't done with a OneToOne. https://docs.djangoproject.com/en/2.1/topics/db/examples/many_to_one/ has more information. Doing this, however, requires us to completely wipe the migrations, because of needing a default ID (house).
mcab
changed the title
This PR allows us to GET / POST data over the API, namely:
House
House Environmental Features
House Physical Features
Observations
They're located at:
/api/v1/house
/house/{pk}/environment
/house/{pk}/physical
/house/{pk}/observations
Where {pk} stands for Primary Key; features and observations are
tied to a specific house, so they belong underneath those API routes.
With this change, certain migrations needed to be deleted in order to
update some ForeignKeys that were invalid.
No description provided.