Open Waidhoferj opened 4 years ago
What do you all think about this new format?
In all seriousness, putting the validation/formatting burden on each Entity itself seems like a MUCH smarter move than trying to externally enforce it. Having an Entity interface that defines a validate and format method to call validators/formatters sounds like a really really smart move to me
It appears that SQLAlchemy doesn't make use of the constructor when it does its magic, so we can just use the entity constructor instead of a static from_dict()
call. Gonna use this implementation in my next PR
Objective
Reduce the scope of the database wrapper to interacting with the database.
Proposal
Require that all Entities have a validator and formatter class attached. By updating this class, we can make our error checking extensible and move most of the logic out of the
database_wrapper.py
file.We have a top level initialization static method on each class called
from_dict(data)
. All of the validation/formatting code in thedatabase_wrapper
could be reduced to the following:Internally this method would incorporate the following:
Examples of validators and formatters can be found the the
./modules
folder.Benefits
Details
Currently the database has formatting and validation functionality baked into the wrapper. The code rigidly enforces that each
Entity
adheres to the keys defined inEXPECTED_KEYS_BY_ENTITY
, but there are cases for the Nimbus Validator App where an ID needs to be passed instead of automatically generated. If I were to change the code in thevalidate_and_format_entity_data()
function, there would likely be other breaking changes.The proposed format would allow me to edit the
QuestionAnswerPair
formatter in isolation in order to field this new use case.