Initial migration to django management

[york-stsci]

This PR includes the following:

• Ran python manage.py inspectdb --database monitors to generate the monitor_models.py file
• Edited the file to remove the managed=False lines, and re-order the databases
• Ran python manage.py migrate --database monitors to generate an initial migration file

In addition, I adjusted the config.json file to point django to both its own default databases and the jwqldb database, but have not yet removed any of the other SQL code.

If I understand correctly what's going on here, it should now be possible to access and update the monitor databases either via Django or via SQLAlchemy (where by "update" I mean "add or edit rows" not "change the composition of tables").

[pep8speaks]

Hello @york-stsci, Thank you for updating !

Cheers ! There are no PEP8 issues in this Pull Request. 🍻

Comment last updated at 2024-02-12 20:29:23 UTC

[BradleySappington]

@york-stsci - verifying that you ran python manage.py makemigrations to actually create the migration file (and if so, you will need to include that migration file in this PR). If you are not including the initial migration, then you can remove that from the PR summary.

[BradleySappington]

You will need to include the initial migration file (does that go in anew folder?)

Please also include the updated example config file that has the new monitors database setup information in it.

[mfixstsci]

Everything looks okay from a coding perspective. Just a couple of questions from me.

[york-stsci]

@BradleySappington apparently when you're adding a new database to an existing installation, it uses the existing file for makemigrations, and migrate.py doesn't (yet) create any new migrations for the new database, so there isn't a new migration file to include.

This is a slight weirdness with django. More or less every django manage.py command takes the argument --database=BLAH and, if you don't include that argument, then it will operate on the default database (only), but makemigrations operates on all databases, and can't be restricted to a single database, but will only check for past inconsistencies and errors in the default database unless you create a router class for the new tables that returns a valid value for its allow_migrate() function. As such, I'm going to create such a file, and also split out the existing monitor_models.py file by monitor, and at that point I'll make another push to the PR (hopefully quite soon).

[BradleySappington]

@york-stsci , just want to be clear. python manage.py migrate will never create any new migration files. That command is the actual act of taking the already made migration files (from makemigrations) and applying them to the appropriate database.

[BradleySappington]

@york-stsci , just want to be clear. python manage.py migrate will never create any new migration files. That command is the actual act of taking the already made migration files (from makemigrations) and applying them to the appropriate database.

[mfixstsci]

@york-stsci all of the model files look good. I spoke with @BradleySappington and we can make sure we dissect all of them when we add the monitors one at a time to make sure everything looks good. I approved it, tests are passing, at this point what's next?

[york-stsci]

I think the only thing remaining is that @BradleySappington requested a code change, which was updating the example config, which I've now done, but I think he has to approve that I've done it before merging is unlocked.

[BradleySappington]

Looks good with this one question