Migratus is a wonderful migration tool for Clojure. You can use it on its own, or if you have a Luminus project, it is already included.
There are a few areas that could use some extra tutorials, though. One of them is code-based migrations. Especially, examples on how to modify the database would be nice.
Here’s a quick explanation of how to modify the database with a code-based migration in Migratus.
First, create an *.edn file in the folder with the regular migrations. It takes the same format as other migrations, so you can really just change the extension of one of your created migrations to ‘.edn’ and change the contents.
You can save a lot of time, money, and frustration by using prewritten libraries and tools when making your full stack apps. One such tool is Redis. Redis is a server that works on most platforms for server-side caching, pub/sub, messaging, Lua scripting, and data structure storage. It is thread-safe, loves puppies and is good with small children.
Seriously, even if you just use Redis as your cache, you’ll save a lot of frustration and make your app scalable.
This tutorial gives an example of using Redis for pub/sub, also known as Publish/Subscribe. All this will be done using Clojure’s Carmine library. (Additional documentation for Carmine found here.
Once you learn Clojure (or any programming language) well enough to tackle a large project, you are going to run into lifecycle, dependency, and state management issues.
Two great resources for handling lifecycles, dependency, and state in Clojure apps are Mount and Component. I use Mount for my projects, but both are popular solutions. This post is about tolitius/Mount.
Create a Clojure Servlet project with the following command.
The important parts of the command are ‘luminus’, which is the framework used to create the Servlet, and ‘+war’, which adds uberwar and Servlet routes to the project. This creates a file called ‘handler.clj’ that replaces the traditional Java Servlet file. The configurations for the Clojure Servlet are found in ‘project.clj’ in the
:uberwar section of the configurations.
By default the lein command above creates a project that will build a WAR file called my-clj-servlet.war, and when deployed will deploy in the my-clj-servlet context, meaning on a default installation of Tomcat you would find the link at http://localhost:8080/my-clj-servlet/
It is important to note that the resulting project from the above lein command actually won’t work as a Servlet, yet. But, we’ll fix that below. The project is configured in the hopes that you can run it from a Servlet container or as a standalone app, and with some massaging, you could. However, this tutorial only focuses on how to get the project compiling as a Java Servlet written in Clojure. If there is enough interest, I’ll write another tutorial on how to get the default project working as a standalone app, and a Servlet.
As mentioned in my other post about plaintext emails, I recommend using the Apache Commons Email library when sending email from Clojure apps. First up, you need to add the dependency to ‘project.clj’
Next, your HTML email has both an HTML version and the alternative plaintext version of the email. Notice, all you have to do is create an instance of HtmlEmail and then call the set and send methods on it using ‘doto’. Pretty easy.
When saving datetimes to databases like MySQL, it is best to save them as UTC instead of using your local timezone. That way, if your company, or IT department, or servers move to a new timezone, you won’t have to worry about adjusting every time stored in the database to match the new timezone. The trick is that you always return UTC times in your APIs, and then expect the clients or tools using your APIs to convert the provided UTC time to their local timezone for display.
This leads to a common question. How do I get the current datetime in UTC when using Clojure?
"Get now in UTC for use in a datetime for a database."
Migratus is a great migration tool for Clojure enterprise projects. Migrations allow you to do and undo changes to a database very quickly. The best use case for Migratus is update of a database for your enterprise project or setting up a new database for a development environment. Setting up the database can be on a production server or your local development environment.
Eventually one of your migrations is going to have an SQL exception. Normally, SQL exceptions aren’t a big deal. You just fix it, and run the migration again. However, Migration gets into an :ignore state and gives you an exception reading …
… and then refuses to run another migration no matter what you do.
The fix is to go into your ‘schema_migrations’ table in your database and remove the row that has an id of -1.
That’s really a simple fix for your favorite Clojure migration tool.
;-) Remember, ... keep your anonymous closures recursively tailed.