Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated database migrations #7340

Open
jojule opened this issue Feb 24, 2025 · 3 comments
Open

Automated database migrations #7340

jojule opened this issue Feb 24, 2025 · 3 comments

Comments

@jojule
Copy link

jojule commented Feb 24, 2025

Integrate and automate Flywheel to Control Center to make database upgrades easy with application version upgrades.

@jojule jojule added this to Roadmap Feb 24, 2025
@jojule jojule converted this from a draft issue Feb 24, 2025
@jojule jojule added control-center Premium Requires Premium or Ultimate subscription labels Feb 24, 2025
@ZheSun88 ZheSun88 added the v24.8 label Feb 24, 2025
@Legioth
Copy link
Member

Legioth commented Feb 24, 2025

I assume we're talking about https://github.com/flyway/flyway and not any of the unrelated products named Flywheel?

I assume this is for the application's own database tables and not for data stored by Control Center?

I assume Flyway would mainly be used directly from the application itself since e.g. the migration files should be under version control. This also means that the database would be automatically updated just by deploying a new version of the application. How would Control Center add value on top of that?

@jojule jojule removed the Premium Requires Premium or Ultimate subscription label Feb 24, 2025
@heruan
Copy link
Member

heruan commented Feb 24, 2025

Yes, it's Flyway 🙂 And yes, this is for the app's database that is created by Control Center that will provide a Flyway bean and configure it to connect to the database and apply migrations read from the app's resources.

@Legioth
Copy link
Member

Legioth commented Feb 25, 2025

That sounds like a relatively small feature at least from a technical perspective? Basically just taking the database configuration functionality that we would have for other cases also and also using it in one more place.

Nothing wrong with that in itself. I'm just somehow expecting that there would be more to it when this is defined as a separate ticket rather than just another case in the #7339.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: June 2025 (24.8)
Development

No branches or pull requests

4 participants