You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Been working to integrate Liquibase with a Springboot project and while I have been able to run the generateChangeLog command via maven successfully I've noticed that all UUID properties I have specified in my entity classes all get translated to char(36) columns in the outputted changelog.
Some output from the above command makes me think it is able to recognize the uuid attributes as UUIDs but something is getting lost during the generation of the changelog:
Manually replacing char(36) with uuid in the changelog and running an update against the db actually does seem to work when updating the actual database but I'd like to avoid such a manual workaround if possible. Is there anything anyone can think of which could be causing this? I saw in another issue that liquibase giving the column char(36) means it couldn't determine the type of database I was using but besides adding the dialect argument to the url above I don't know what else would indicate this to liquibase.
Got debugging with the maven command to work and I can see that my database is null when Liquibase checks the database type as mentioned here: #166 (comment)
Hello,
Been working to integrate Liquibase with a Springboot project and while I have been able to run the generateChangeLog command via maven successfully I've noticed that all UUID properties I have specified in my entity classes all get translated to char(36) columns in the outputted changelog.
Command:
./mvnw liquibase:generateChangeLog -Dliquibase.verbose=true
Some output from the above command makes me think it is able to recognize the uuid attributes as UUIDs but something is getting lost during the generation of the changelog:
Sample Entity Snippet:
Sample changeset in generated changelog:
Manually replacing
char(36)
withuuid
in the changelog and running an update against the db actually does seem to work when updating the actual database but I'd like to avoid such a manual workaround if possible. Is there anything anyone can think of which could be causing this? I saw in another issue that liquibase giving the columnchar(36)
means it couldn't determine the type of database I was using but besides adding the dialect argument to the url above I don't know what else would indicate this to liquibase.Some details:
liquibase.properties file:
Maven Plugin config:
The text was updated successfully, but these errors were encountered: