(Please let me know if there is a better channel to put this): I have been tasked with upgrading processes for database migrations in a legacy Lucee v5 application (not using any frameworks) with a MySQL db. Currently there is no pipeline/process for updating the db schema and we just run sql scripts manually on the db instances when needed for a new release. I think we need to use something like Flyway to manage migration scripts and database state, but am trying to figure out how to integrate it to an existing project/databases, and have some questions for anyone who can help me out with this... 🧵

You can use cfmigrations without Coldbox. Or commandbox-migrations (same thing just from Commanmdbox). Never used Flyway by cfmigrations is easy peasy

Hmmm, okay I haven't looked into that yet. That opens a new can of worms to get into, but I'll explore that option.

Cfmigrations is nice because you can just write the migrations in CF and have it test for environment or whatever else you want

Definitely going to look into it. Flyway is easy to understand just because it is completely SQL script based, which fits into our current process, but if cfmigrations makes anything easier I'm all for it.

The trouble you run into then is making SQL aware of everything it needs to know for each migration. Cfmigrations was a lifesaver for us years ago and it's one of my favorite headaches I no longer have 🙂

I have to say, that at this point I'm at in the rabbit hole, I'm going with Flyway. My understanding is I just need to: • Generate DDL and reference data with something like

mysqldump

to establish a baseline for the existing database version • Start adding scripts in a sql folder versioned above the baseline that will function as a append-only log of the state of the database And, I think that's about it. Adding the reference data to the baseline startup script will need to be done with care, but it just seems so simple this way. If there is something I'm missing out on using CFmigrations, I'm all ears - to be honest, I didn't really understand the comment about "making SQL aware of everything it needs to know for each migration".

You'd mentioned different migrations based on environment. We have migrations that only apply to our test suite database. Plenty of ways to do that, but easy with cfmigrations because it only runs on our test harness. Others only run on production. Not knocking Flyway, I've just never heard of anybody in CF land using it

Hmmm...ok, that does concern me if Flyway isn't used in cf projects. It just seems so simple, but I don't want to force a square peg in a round hole and don't know what I don't know being relatively new to the CFML/Lucee/CF world..

I can't say it isn't used, just that I've never heard of it. Cfmigrations is used all the time. But the CF world is a weird little place sometimes, so if you like it and it gets the job done, go for it