Accessing properties via Props in SBT

[Nathaniel Ford]

Hi!

I'm trying to access properties from my liftweb properties file in my build.sbt file. Full details are here: 

http://stackoverflow.com/questions/38779846/utilizing-library-dependencies-in-sbt-plugin

But the upshot is that:

- I'm attempting to use flywaydb with Slick and liftweb (this part is successful)

- I'd like to pull the connection properties from the same place that the application does (where I'm struggling).

The latter issue revolves around being able to use a library that I'm importing (via libraryDependencies, specifically the liftweb library that contains Props) to get access to the application's connection properties. I'm not sure if I need to build my own plugin, if there is a liftweb-related plugin that already exposes those libraries to the sbt itself, or what? The SBT documentation is notably unclear on this particular need, either in it's TOC or searching (where it mostly assumes you are trying to manage libraries for use in the app, rather than for use in the build script/sbt itself).

I'm posting this here because it's possible I'm heading down a ridiculous and/or awkward track. Ideally, I'd like my sbt to control the build and testing of the application as well as the db migration (which will be different for building and testing: MySql for one and H2 for the other), depending on the task I'm executing. But maybe people with Actual Real World Lift experience know a better way to think about this structuring?

Thanks for your help!

-Nathaniel Ford

[Diego Medina]

Hi Nathaniel,

Others may reply to the part about writing an sbt plugin, etc, but what we have been doing on production and has worked well for at least 3 years is to have the db migration code all inside the actual app, instead of being delegated to an sbt task that you manually run.

Granted I didn't write it (All credit to Tim Nelson)  , but iirc part of it includes what Matt Farmer did on this project 

https://github.com/farmdawgnation/anchortab/blob/master/src/main/scala/bootstrap/liftweb/Boot.scala#L34

(which is great that he open sourced)

The way it works for us is:

1. Boot.scala we call a method on our Migration object, doMigrations()

2. doMigrations() gets the latest version of the running database (we have a table (we use Mongo so technically it's a collection, but it's the same for MySQl, let's call it a table from here on)) in this table, every time you run a migration, we add one row, with the description of the migration and then a numeric id, it's sequential, starting at 1.

3. Then we compare that to the latest migration number hard coded in our app, we have this on another object called MigrationVersion, a val called "latest"

so then we do something like:

    (versionStoredOnDatabase+1 to latestVersionFromMigrationVersion).foreach { ver =>

      ver is the version so here we use reflection to find the migration classes, run the,. save the migration id and description to the database so we don't run the migration twice, etc. I think this is where you will want to call flydb

    }

so this will run every migration we have  so that the database migration version matches the last one we added to our app.

And once the migration(s) are done, then Boot continues with the normal initialization and then our app is running again. No sbt needed, and it runs just fine locally in dev mode, on our staging, pilot and production servers.

In our case we have several web servers, so we run the migration on a dedicated server and then the rest of the app on the web servers continue to run, but I think you get the idea, if you need any more info on this way of handling migration, just let us know here.

Thanks 

Diego

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
http://blog.fmpwizard.com/