https://kotlinlang.org logo
#getting-started
Title
# getting-started
n

Nat Elkins

01/11/2021, 4:25 PM
d

diesieben07

01/11/2021, 4:27 PM
If you are on the JVM I'd recommend Flyway: https://flywaydb.org/
m

Matteo Mirk

01/11/2021, 4:28 PM
yes, that or Liquibase
n

Nat Elkins

01/11/2021, 4:28 PM
Looks like what I want, but is it free?
m

Matteo Mirk

01/11/2021, 4:29 PM
it has both free and paid options
n

Nat Elkins

01/11/2021, 4:32 PM
Got it, looks like it can do just fine with the free option, the paid stuff are things like advanced auth and storing migrations in various cloud storage providers.
d

diesieben07

01/11/2021, 4:32 PM
Yes, I've never needed anything beyond the free version
n

Nat Elkins

01/11/2021, 4:33 PM
Is it something you run as part of your deploy step?
That's basically what I'm looking for
d

diesieben07

01/11/2021, 4:35 PM
You can either do that (run it standalone using the
flyway
CLI), or you can just add it as a maven dependency and call it programmatically from within your application before starting up
n

Nat Elkins

01/11/2021, 4:37 PM
Thanks. Do you have any opinion on Liquibase vs Flyway?
d

diesieben07

01/11/2021, 4:39 PM
I haven't used Liquibase. Looking at it, Liquibase requires you to write XML and... yeah no thank you. With Flyway you just write the SQL to perform the necessary changes.
Ah, no, Liquibase has SQL, too. Then I can't really comment 😄
a

Alex Nordlund

01/11/2021, 4:40 PM
Liquibase is my favourite
also you can write yaml, json, xml, or sql
n

nanodeath

01/11/2021, 5:27 PM
+1 for LiquiBase. the XML really isn't that bad, and yeah you do have to (get to?) write SQL sometimes...some of the more advanced features (triggers) are only covered in the pro version, but writing your own SQL is an easy workaround.
n

Nat Elkins

01/11/2021, 5:49 PM
I prefer writing SQL actually, I've found in general getting as close to the SQL as possible makes debugging so much easier down the road.
n

nanodeath

01/11/2021, 5:52 PM
fair point -- so with LiquiBase you can run the "update" target and it just connects and executes the code, but if you run "updateSQL" it spits out all the SQL it will execute. I review this and copy-paste this into my code reviews, so we know exactly what it's doing
and, there's a futureRollbackSQL command that emits the SQL needed to rollback the change if/when it goes live. I also include that in the code review, so that worst case we can panic and easily find the SQL we need to run directly
m

Mattia Tommasone

01/11/2021, 8:17 PM
i have been using liquibase for more than a year and also contributed some code to it. this being said, i don’t think it’s really kotlin-friendly for one main reason: it does not support adding a non-nullable column to a table in a single changeset, which means that you have to add properties in two steps if they are meant to be not nullable: • add them as nullable --> deploy • remove the ? to make them non-nullable --> another deployment
apart from this, it works pretty well in my environment, we run the changelog generation inside gradle builds and apply the changes upon production deployments, it’s (almost) entirely transparent to us
6 Views