longevity

A Persistence Framework for Scala and NoSQL

View project on GitHub

project setup for longevity migrations

In addition to the library dependencies you set up for longevity proper, you will need to add another library dependency to your build.sbt for migrations:

libraryDependencies += "org.longevityframework" %% "longevity-migrations" % "0.26.0"

You will also want to add the sbt-longevity-migrations plugin to your build by adding the following line to project/plugins.sbt:

addSbtPlugin("org.longevityframework" % "sbt-longevity-migrations" % "0.1.0")

The longevity-migrations library dependency will move in lock-step with the other longevity artifacts. However, the sbt-longevity-migrations plugin maintains its own version and release cycle.

Enable the SBT plugin back in your build.sbt:

enablePlugins(longevity.migrations.Plugin)

The plugin requires the following two settings to be added to your build:

modelPackage := "com.example.domain"
migrationsPackage := "com.example.migrations"

The modelPackage is the package where your domain model classes are found. The migrationsPackage is a package to contain your migrations and your model tags.

The code for these packages is assumed to live in the standard locations. In the example above, the plugin will look for model code in src/main/scala/com/example/domain, and migrations code in src/main/scala/com/example/migrations. You can override these locations if you like with settings modelSourceDir and migrationsSourceDir. For instance, if you leave out the com and example directories in the middle, you could specify this like so:

modelSourceDir := (scalaSource in Compile).value / "domain"
migrationsSourceDir := (scalaSource in Compile).value / "migrations"
prev: migrating to a new version of your domain
up: migrating to a new version of your domain
next: tagging a version of your domain model