Springboot Migration Automation
Is there a way to generate an SQL file for all changes that happens to my entities each time i start my app such that i can copy/paste this sql file into my production and manually alter my tables after i finish working on a feature in springboot that would change some entities?
57 Replies
ā This post has been reserved for your question.
Hey @Saeed Muhaisen! Please useTIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here./closeor theClose Postbutton above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically marked as dormant after 300 minutes of inactivity.
im not sure if thats what you need but you may look into liquibase
if you know a better aproach please let me know
you can use automatic DDL upgrading on your local machine (with a DB in Docker) and enable SQL logging
then you get the SQL statements in the console
great sentence
:GnuTrolling:
nooooo
shouldve kept it
damn what did i miss
this is too exhausting, i am currently considering flyway
I meant if you want to generate the SQL you can then tweak and put in the migration script
yeah
I am reading more and more and i feel its not good approach
I feel there must be a better way to track changes
I wonder what happens in real companies how do they handle this
it can be useful as a starting point for writing the changes
this is very similar to what i do currently
every release i generate new file from local db, and compare with prev generated file and do my own script
typically either SQL first and then the entities or do the entities and then write the SQL manually ig
yup, this is most of the things i am seeing online.
but its weird that java springboot community hasn't figured out a better way
i work currently in python django and we can just create a migration file which would run automatically when we push to production cicd
the thing is you typically want to specify it manually
flyway is doing that
would you say its good to go with flyway?
but the migration file is SQL
yes
but wouldn't this mean i will have to give my springboot app the power to update the database directly?
i used to think this is bad approach and can cause issues, i always seperated between the two
springboot app has read write on tables but database owns everything
I thought you were talking about how to write the SQL content?
nono i am generally speaking about the approach
i have app on production, i currently do update manually before each release then i do the release in aws
I think you can specify different credentials for flyway
like update database then push new release image to docker
but it's still in the same application
but is this safe
and yes you could also run flyway in your CI/CD pipeline but this is typically not done
yeah idk too many options
I might use flyway and manually apply the changes copy pasting them
on db
doing it in the pipeline also has issues
yeah i wouldn't dare do that
many things can go wrong
Like you don't want the migration when the application is still running
and if the app does it, it can do so on startup (and rollback if it fails)
i read rollbacks are premium on flyway and liquibase
What?
not with flyway AFAIK
yeah you have to be on premium on flyway to do rollbacks
ah ok
you can just create another migration though
yup+
ii think i will go with flyway and create the V1__ files, then manually apply them on database whenever a release must happen
well that's adding another step to releases
typically you'd want releases to be automated
Yeah for sure but i feel this is the only approach that gets applied in production in corprates.
i am thinking like:
1. add flyway
2. with each feature creation i create VXfeature.sql file and RXfeature_rollback.sql
3. before release run VX__feature on database
4. push the new release to the server
anything goes bad i would use RX_feature_rollback
and i think later i can make a cicd for the whole process
flyway does support that both at startup and with scripts I think
i want to not give it too much power
but the rollback is a premium thing
you can still do it in the CI
i want to do it manually in script
yeah
if you add manual steps to your release process, that's your decision
Dealing with databases is just next level stress š
manual might save me from catastrophes
backups actually save you from catsstrophes
Yeah i am trying to save some $$
the biggest risk is you making a mistake innthe migration script
and you messung up the manual step - e.g. forgetting to run it
and if something goes wrong you can still do a rollback even with the free version
So in your opinion i should do flyway with direct access to update
probably- either that or in a CI if this is applicable for your application
i think ill go flyway with direct access
i am going to test it locally and see
if its not scary ill do ti
the main risk there is your migration script doing something stupid
yup, and idk if flyway would allow me to run the script before runnign springboot but i think that is available
and is there really much of a difference between your application deleting all data and your application dropping tables?
you should be able to use flyway in a standalone way
true
I think there's even a Maven plugin but idk what exactly that does
ig you could do flyway and liquibase
if they support each other
for even better experience
š±
where's the better experience in using both?
It will be headache managing both of them
managine oneself is already sufficient headache
to better feel the pain of managing 2 of these at once
l0l
š¤ Post marked as dormant
This post has been inactive for over 300 minutes, thus, it has been archived.
If your question was not answered yet, feel free to re-open this post or create a new one.
In case your post is not getting any attention, you can try to use /help ping.
Warning: abusing this will result in moderative actions taken against you.