Closed ianco closed 5 years ago
With regards to question #2:
Ensuring that the django migrations could from the empty state all the way to the current state (first adding many models, then removing them after adding new v2 models) meant that some history of the v1 models needed to stick around.
It should be possible to create a new initial custom migration that sets up all of the database schemas so that the v2 migrations run from this new initial state. That would allow us to completely delete the old migration history.
@nrempel thanks for the review. W.r.t. re-naming files I'd like to take this for future reference (the move to IndyCat) but leave as is for now (all model files are currently CamelCase so would need to change them all).
Moved User model from api app into api_v2 app (manually moved the migration history). api_v2 can now be packaged as a stand-alone django app.
Note - Also include django upgrade to 2.1.5
Re-factor orgbook code into two packages:
api_v2 - code orgbook django app, can be run in stand-alone (read-only) mode (./manage start seed= DEBUG=true) with pre-loaded data
api_indy - Indy-related dependencies (normal OrgBook with support for register issuer, issue credential and provide proof)
Requires one additional startup parameter (APP_FILE=app_vonx.py) to explicitly declare the s2i startup for "normal" mode.