CLI: enroll_db

[pydanny]

This PR adds a CLI command for enrolling a DB, which also does its best to add an initial migration. After a warning the user can reject the initial migration through the dialogue.

If the user wishes to force the CLI to skip the querying, they can use the --force flag.

• Add enroll_db function, evolving from _ensure func
• Add CLI functions for enroll_db and get_db_schema
• Add tests
• Provide suggested first migration
• Document these changes
• Passing tests
• Perform full lifecycle check of versioning and running migrations

[algal]

@pydanny Just to confirm: this is still in draft, but you'd like me to look at it now?

[pydanny]

@algal Still in draft, there's a regression failure I need to fix.

[pydanny]

@algal I created a new virtual environment and manual tests all now pass. So it was an issue with my local development environment, not a regression.

[algal]

@pydanny Hi Danny, I have reviewed this.

In a Discord thread this morning (which I think you caught half of), @jph00 specified what he would like the enroll_db command to do:

I just want a command that:

• Dumps my schema to a .sql file
• Adds a table to my DB that says I'm now at v1

So I reviewed this PR based on what is needed to move toward that specification.

Reviewing this PR, in particular the command behavior defined in lines L148-182 cli.py (starting at

fastmigrate/fastmigrate/cli.py

Line 148 in 53f39fa

db_path, migrations_path = _get_config(config_path, db, migrations)

), it seems like this is what your PR already does except for three things:

1. In this PR's enroll_db CLI command, the command asks the user if they want to dump the schema before it proceeds to update the DB version to 1.
2. This PR also adds an enroll_db command to the API.
3. This PR also adds a get_db_schema CLI command.

In order to fit Jeremy's spec, I'd suggest the following changes.

1. Regarding the enroll_db CLI command.

   • The command should not ask the user for confirmation. Just dump the schema, update the DB version, and then tell the user that both things were done. (It is then up to the user to verify that the updated DB, and the schema, are aligned. They can read docs if they want to go deep on that. But the goal of this design is the create a simple tool rather than to educate them about sharp edge cases.)
   • The command should exit with an error, without doing anything, if dumping the schema would overwrite a file already existing at that path.

2. Regarding the enroll_db API command, I'd remove it from the public API by making it private. This is rare action, and it is sufficient to support it from the CLI. And If we remove it from the API, then we don't need to worry about CLI and API command being behaviorally different.

3. Regarding the get_db_schema CLI command, I'd remove that too. It's easy enough to do from sqlite3 directly. My thinking here is that fastmigrate overall will be easier to use if it exposes only what is needed, rather than trying to abstract over the sqlite interface.

@jph00: Please let us know if this sounds off-base to you, based on our discussion.

[algal]

Added comments in conversation, on my recommendation for changes to simplify this based on Jeremy's spec for enroll_db.

[jph00]

Thanks @algal . My main request is to remove nearly all the code from this PR -- aim for under a dozen lines (not including docments et al - just counting actual logic).

I prefer not to have private APIs where possible. But if the CLI just calls the API directly, that should keep things consistent IIUC.

[pydanny]

To keep things simple on my end, I've started a new branch. The PR for that branch is here.

[pydanny]

Hey @algal and @jph00, thanks so much for the reviews and feedback! Looking at this PR now I see in hindsight the scope got way too large. I've extracted, recoded and rewritten the PR as #23, focusing on the changes you requested.

Thanks to the schema code I did have to go over the requested line count. The issue there is making sure the initial migration is guaranteed to work on an existing SQLite db. I'm keen to learn of any methods I can use to cut down the line count further.

Closing this now as the work is now taking place in #23.