dmeliza
commented
4 years ago The views/forms that we need to have:
- summary of contents of each nest. Links to add eggs, hatch
them, remove dead birds/eggs, and confirm the contents.
- status in each nest by day since establishment (number of eggs and
chicks). This is somewhat redundant, assuming that events are entered
correctly.
- forms to create and disband nest
The models need to be updated as follows:
- add is_nest boolean field to locations so that nest summaries can be
restricted to breeding cages
- add in_egg boolean field to animal so that "age" can be calculated
appropratiely relative to hatch or lay date
Logic:
- nest should only have one parent of each sex. Do not allow more than one
adult bird of each sex to be added to nest locations.
Workflow:
- every day, pull up nest summary. Click links to add/remove eggs or
hatch/remove chicks. A confirm link adds a note for each chick/egg. All
of these should return back to the nest summary so that each operation
takes a single click.
Currently we're using a google spreadsheet to do daily nest checks, and there's a lot of duplicated effort and opportunities for error. It would be nice to have nest checks integrated with the colony database.
Simplest implementation I can think of is with a Nest model, then add a ForeignKey to Animal so that birds can be added or removed from a nest. The Nest model itself would have a location, a name, and an egg count. But this would only hold the current state of the nest, whereas we want to keep a record. Among other reasons, having a date when eggs are laid would allow predicting when they will hatch.
We already keep records in the form of Event objects, but these are linked to animals and locations, so it wouldn't be trivial to make them work for a separate model. Thus, another option is to extend the Location model so that it can be used as a nest. Eggs probably have to be tracked as unique objects, whether as weird Animal instances or using their own somewhat simpler model. In this approach, a lot of the logic would be in the views.
The problem I see here is that Animals don't have a unique Location; instead, this is inferred by joining to the Event table and finding the most recent event. This works nicely for 90% of the logic, but it's not simple to go in the reverse direction, from Location to Animal, at least not with the Django ORM.