latentprion/cppbessot
1
0
Fork 0
mirror of https://github.com/latentPrion/cppbessot.git synced 2026-06-23 15:18:37 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add migration commands for SQLite; not PGSql

Browse Source
This commit is contained in:
Hayodea Hekol
2026-04-29 23:19:50 -04:00
parent e12ad0ecac
commit 68724dff8f
34 changed files with 1289 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/prompts/add-migration-cmds-prod-proddev-dev.md
+24
View File
@@ -0,0 +1,24 @@
Ok. Now we need to add the concept of migration action targets. Add new vars: these control the global migration action target. These don't determine the generated source oas, or the target dir to generate that oas into. Rather, they determine the target DB to apply the current DB_SCHEMA_DIR_TO_GENERATE schema against.
The new var name is: DB_TARGET=<prod|proddev|dev>.
It's expected by the parent source dir that DB_TARGET either already is already migrated to DB_SCHEMA_DIR_TO_GENERATE; or DB_TARGET will be migrated to DB_SCHEMA_DIR_TO_GENERATE before the application is compiled and executed. It is in fact the parent application that sets DB_SCHEMA_DIR_TO_GENERATE, after all.
Prod and dev are self-sufficient targets. Migration actions applied to them are applied to them qua independent, persistent db.
* Action: target db_createfrom. Accepts option DB_CREATEFROM_SCHEMA_DIR=<schema dir>. Respects and uses CPPBESSOT_WORKDIR. Will use the pre-generated sql_ddl artifacts in <schema dir> to idempotently create a new db with the name prod or dev, depending on the value of DB_TARGET. Default ON_TARGET=dev. Default value of DB_CREATEFROM_SCHEMA_DIR is DB_SCHEMA_DIR_TO_GENERATE. Obv a non-existent DB_CREATEFROM_SCHEMA_DIR or one whose oas spec doesn't exist, will result in an abort.
Proddev is copied from prod. It is a sandbox target used to apply migrations against a clone of prod.
* Proddev does not support the db_createfrom target. It is always cloned from prod.
* Action: target db_migrate with DB_TARGET=proddev will always automatically and idempotently clone prod to a copy called "proddev", unless the DB_MIGRATE_PRODDEV_USE_STALE=ON flag is set. This flag simply means "Don't clone. Re-run the current target action against the most recent, stale cloned proddev, which is itself a prior clone of prod". Specifying DB_TARGET=proddev and running db_createfrom is illegal and should abort. Speciying DB_MIGRATE_PRODDEV_USE_STALE=ON and running target db_migrate when no current stale prod DB exists results in an abort.
Action: Target db_migrate: Option DB_TARGET=<prod|proddev|dev>. Option DB_MIGRATE_WITH=<migration from-to-dir>. If the <migration from-to-dir> doesn't exist, this aborts.
Each DB migration from-to-dir may have two shell scripts: pre-structural-backfill.sh and post-structural-backfill.sh. The db_migrate target should check to see if these scripts exist, and if the pre-structural-backfill.sh script exists, it should be executed before the structural migrations, if any. If the structural migrations generated by the db_gen_migrations have content, then they should be applied next. Then if the post-structural-backfill.sh script exists, it should be run last.
Think of as many tests as you can to give coverage of all of these new commands as well as the sqlite and pgsql variants' behaviour and write them first before implementing this plan.
Be very aggressive about splitting and isolating code into common subfunctions and modules, and reusing wherever possible. Don't duplicate code. No long-scrolling functions.
----
That sqlite_apply.py script: can it be done as a bash script instead?
I'd prefer to add the sqlite3 cli to the project's CMake find_* targets, than to add python unnecessarily.