NO TICKET: datetime format fix, README update, enums

[jacob-a-brown]

Why

This PR addresses the following problem / context:

• @chasetmartin and I were having trouble pulling data when developing locally because of an enum issue, but then we figured out it was as easy as setting MODE=development in .env because otherwise the enums are made before the lexicon tables are populated. Once we determined this was the issue we thought updating .env.example and README would suffice for future developers
• In the process of figuring out this problem, we found that the @model_serializer was not necessary for the BaseResponseModel
• Not all enum-restricted fields used those enums in their Create, Update, and Response models

How

Implementation summary - the following was changed / added / removed:

• Use bullet points here

Notes

Any special considerations, workarounds, or follow-up work to note?

• I put DT_FMT in schemas/__init__.py from tests/__init__.py so it can be used in both schemas and tests. I also removed microseconds from the format as that seemed extraneous.
• @jirhiker: currently lexicon and parameter tables are only populated on spinup if MODE=development. Does it populate it for production? If not should it?

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

Files with missing lines	Coverage Δ
core/enums.py	100.00% <100.00%> (ø)
schemas/__init__.py	85.00% <100.00%> (-1.67%)	⬇️
schemas/field.py	100.00% <100.00%> (ø)
schemas/location.py	92.59% <100.00%> (ø)
schemas/observation.py	98.38% <100.00%> (+0.02%)	⬆️
schemas/parameter.py	100.00% <100.00%> (ø)
schemas/publication.py	100.00% <100.00%> (ø)
schemas/sample.py	98.33% <100.00%> (ø)
schemas/sensor.py	100.00% <100.00%> (ø)
tests/__init__.py	100.00% <ø> (ø)
... and 9 more

[jirhiker]

No database population should happen during launch of the api. The api should assume data is in the db. If data is not in db, api should not start. The db population should be handled by a separate process that runs the transfer.py script

[jacob-a-brown]

In that case should we make the enum population a function that can be run at the end of transfers/transfer.py::erase_and_initialize so they are populated for the API? Or is it okay as-is?

[jirhiker]

The enums need to be constructed when running either the api or the transfer script.

[jacob-a-brown]

As you wrote earlier if the DB is already populated then the enums will be populated during spin up. I'm not too sure how we can get them populated after running the transfer script. I could, however, put the transfer script in the docker entry point before spinning up the app so that they get populated automatically? Or is that not necessary at the moment, when all we really need to do locally is set MODE=development in .env?

[jirhiker]

Why does mode have any effect on the enums? Enums are populated with valid values from the lexicon table. So when running tests or the transfer script the lexicon table needs to be written to before any enums are used. This is why schemas are imported locally in some of the transfer scripts. Another option would be to populate the enums from the json file but this has other consequences

[jacob-a-brown]

If MODE is not development then the lexicon tables are not populated, so during spin up of the app and DB with docker each of the enums in core/enums.py are empty. The response schemas that use an enum, like ReleaseStatus, raise errors because they are also empty so none of the values are there (e.g. "draft" or "private" in tests)

Instead of using MODE we can populate the lexicon and parameter tables in entry-point.sh so that when we spin it up during development those tables will be populated and the enums will be constructed correctly

[jirhiker]

Is mode being used by api or just by docker? I don't use docker for development of the app. I use it just for hosting a db so maybe that's why I'm not encountering any issues

[jacob-a-brown]

It's being used by the API and the CD scripts, but not by Docker directly.

[jacob-a-brown]

When I run the tests it works fine because a new app is spun up after lexicon and parameter are populated, but I also use Docker to run and spin up the app locally for debugging purposes (and to see how it's working/the documentation).