Currently it is required that the DB and YAML not only have a
flat structure, but that the field names match parameter names.
These changes incorporate transformation functions to avoid this,
and introduce constants to enforce common naming across the entire
system.
This is by no means the ultimate replacement to a full-fledged
ORM! With that said, introducing an ORM doesn't seem entirely
necessary at this point given there is only 1 table. Also,
given that the project also uses YAML, 2 ORMs would be required
to avoid this kind of stuff.
For the time being, this offers decent enough flexibility in the
absence of an ORM(s).
Currently it is required that the DB and YAML not only have a flat structure, but that the field names match parameter names.
These changes incorporate transformation functions to avoid this, and introduce constants to enforce common naming across the entire system.
This is by no means the ultimate replacement to a full-fledged ORM! With that said, introducing an ORM doesn't seem entirely necessary at this point given there is only 1 table. Also, given that the project also uses YAML, 2 ORMs would be required to avoid this kind of stuff.
For the time being, this offers decent enough flexibility in the absence of an ORM(s).