For the normal data storage in most of todays applications a relational DB is not the optimal solution for several reasons. There are many great alternatives now on the market. I like MongoDb because it is not that far away from the concepts of a relational DB, it is easy to set up and has proven to be stable and reliable.
Thus I clearly want a MongoDb as persistence in my Play 2! project. Goal is
- to have a good abstraction. Not too much magic but not too much boilerplate either
- to have it running locally and in the cloud (I’ll go for Heroku here)
I found Salat a pretty good abstraction. It got it running quickly locally. But when I tried to get it running on Heroku it became a little awkward. At Heroku – as on every other PaaS I had a look at – you get a URL for the MongoDb you added to your app, normally provided as system property. Same holds if rent a DB in the cloud at a “pure” cloud DB provider. But there are no means (that I know of course) to easily let Salat read and use the URL.
So I wrote a MongoDao that does the following things:
- it reads a MongoURL defined in the application.conf via the mongo.uri property.
In my template application I provided an example that reads the environment variable MONGOLAB_URI which is the system variable on a Heroku app with an installed MongoLab instance. If no such variable is set, the property is left empty. This lets the MongoDao take the standard parameters for a local MongoDb installation.
- a collection method that returns a collection as required by the SalatDao, so you can easily define the SalatDao in your implementation
- if you want to differentiate between different local DBs you can overwrite the defaultDbName val in you class.
This is pretty much it. If any one of you has good ideas to make the abstraction more convenient, clean, elegant I’d be happy to read your comments.