This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-05
Channels
- # aws-lambda (1)
- # beginners (294)
- # boot (35)
- # cider (19)
- # cljs-dev (39)
- # cljsrn (7)
- # clojars (48)
- # clojure (266)
- # clojure-android (1)
- # clojure-brasil (1)
- # clojure-france (2)
- # clojure-greece (5)
- # clojure-italy (7)
- # clojure-mexico (1)
- # clojure-russia (24)
- # clojure-spec (10)
- # clojure-uk (31)
- # clojurescript (134)
- # consulting (7)
- # cursive (69)
- # datomic (20)
- # emacs (57)
- # events (2)
- # figwheel (2)
- # hoplon (1)
- # jobs-discuss (19)
- # luminus (33)
- # lumo (18)
- # mount (1)
- # off-topic (32)
- # om (5)
- # onyx (27)
- # pedestal (15)
- # re-frame (12)
- # reagent (28)
- # rum (2)
- # schema (2)
- # spacemacs (9)
- # unrepl (2)
- # untangled (7)
- # vim (5)
- # yada (4)
Just read through http://www.luminusweb.net/docs/migrations.md and found this passage:
The migrations will be packaged in the applications when it's compiled. This allows the application to apply its own migrations when deployed to the server:
lein uberjar
java -jar target/uberjar/<app>.jar migrate
I noticed that the Procfile
doesn't have migrate
at the end of the command. What is the recommended way of automatically performing migrations when deploying (to for example Heroku)?@curlyfry i would recommend one of two ways
first, is using Release phase https://devcenter.heroku.com/articles/release-phase
you put a release: java -jar target/uberjar/<app>.jar migrate
in your Procfile
and it automatically runs in it's own dyno after a deploy
or you can run it on demand with $ heroku run java -jar target/uberjar/<app>.jar migrate
. But you'd have to ensure that your new code can run momentarily w/ the old schema (or accept a period of downtime)
@codefinger Awesome, thanks a lot! I'm using migratus-lein, so I'll probably go with release: lein migratus migrate
@curlyfry hmm, one problem with that is making sure the lein env is available at runtime. by default it's not, and you might end up re-downloading all dependencies
i tend to recommend the java -jar
approach for running stuff other than the build
but you can $ heroku config:set LEIN_INCLUDE_IN_SLUG=yes
it will increase the size of your slug significantly though
(because it keeps the .m2
dir)
Interesting! So I would simply run just the migration code and then exit when the program gets migrate
as an argument? (Can't check right now of that is how it's done in Luminus)
@curlyfry yea. i'm looking at migratus now (i'm not familiar with it). It is very lein centric. other frameworks make it a little easier to run from code, such as flyway https://devcenter.heroku.com/articles/running-database-migrations-for-java-apps#running-flyway-with-the-java-api
I'm sure it's possible. I'll see if i can make an example
@codefinger Couldn't I use this api? https://github.com/yogthos/migratus#usage
@curlyfry oh yea, totally. that's the ticket
My only annoyance now is that I can't seem to figure out if I will need to duplicate my migratus config if I wan't to use it both from leiningen and from code
@curlyfry it's still in beta, so i'd love to know how it works for you so we can improve the UX as needed (I work at Heroku). the output is a little hard to find (you might need to look in http://dashboard.heroku.com)
I would recommend just updating the main function in the core namespace of the app to run migrations based on on env flag
@yogthos So your recommendation would be to (in -main): 1. Run migrations if a prod env flag is set, and 2. init the app as usual?
I'll explore both options, thanks again @codefinger and @yogthos!
Running Luminus server/client (term1: lein repl (start), term2: lein figwheel) and am able to connect to the server, pull down the /docs and figwheel displays the repl prompt. Everything works great except figwheel doesn’t compile/hot-reload changed files.Looking at the chrome debugger sources pane I see that the same handlers.cljs lists one handlers.js file and server other handlers.js?zx=<some random string>
I’m guessing this is why the source maps aren’t pointing to the most recently compiled handlers.js file
This probably isn’t a luminus problem proper but maybe someone here has run across this before given that I generated this app using the luminus template.