Updates Alembic migration to better match SQLAlchemy models
The original Alembic migration script was autogenerated, then
subsequently modified by hand. Between these two aspects, some
correspondence to the corresponding SQLAlchemy models was lost:
* Columns were specified independently of corresponding foreign key
and primary key constraints; besides making it more difficult to
follow the code between models and the migration script, there was a
loss of integrity constraints: a variable association must exist for
every entity that mixes in VariableMixin as a base was not being
enforced at the database level with an appropriate not-null; this
causes problems for use of variables for any such object that is not
constructed by models code, most notably via direct usage of the
database. (See specifically https://bugs.launchpad.net/craton/+bug/1668251, fixed with this
change.)
* The column created_at would always be set by model-using code; but
this was not enforced at the database level by ensuring it was not
null.
* Children should be deleted if the parent is deleted (we do not
support "soft delete" in Craton).
In addition, all constraints are now named (the original intent of
this change, so as to ensure the feasibility of future migrations),
and they are also named in a consistent fashion.
Note that this change does not support many-to-many deletions (as seen
in https://bugs.launchpad.net/craton/+bug/1668308), but SQLAlchemy
does provide support for this at the model level. A future change can
address this without requiring Alembic support.
There's no direct testing of this change, but it is implicitly, and
rather strongly, tested by the overall functional tests that are used;
and to a lesser extent by some of the unit tests. This is in part
because this change has strengthened constraints, not weakened them.
Responses generated from failure should be JSON formatted.
flask_restful.Api is subclassed to control the format of all error
responses generated by the API Flask app.
The API middleware is modified to use the same error response function
given that it is not part of the Flask app for the API. Any Response
object created by the middleware has been converted to an exception to
ensure that all error responses are generated using the same code.
The use of abort has been replaced with raising exceptions, this further
consolidates the error response mechanism.
response_filter has been modified so that it always expects to receive a
response tuple now that http_codes is no longer there to return a
response object.
The error filters in schemas.py have been removed. These were not used
by the existing code.
bb515d4...
by
Michael Porras <email address hidden>
Adding wrapper functions to tools
Adding wrapper functions to the tools directory. Updating development docs
advising users to clone the sample config to a dev config. The dev config
allows users to launch craton directly and in docker without constant config
changes.
