The latest version of this plugin is for Play 2.4+, and can be enabled by adding the following dependency in your project/Build.scala (or build.sbt).
When the dependency to the Play plugin is used, no separate dependency to the ReactiveMongo driver must be declared, as it will be resolved in the appropriate version by the transitive dependency mechanism.
As for Play itself, this ReactiveMongo plugin requires a JVM 1.8+.
If you want to use the latest snapshot, add the following instead (only for play > 2.4):
ReactiveMongoPlugin is deprecated, long live to ReactiveMongoModule and ReactiveMongoApi.
Play has deprecated the plugins in version 2.4, therefore it is recommended to remove the former ReactiveMongoPlugin from your project. It must be replaced it by ReactiveMongoModule and ReactiveMongoApi which is the interface to MongoDB.
Thus, the dependency injection can be configured, so that the your controllers are given the new ReactiveMongo API.
First, Add the line bellow to application.conf:
Then use the Play’s dependency injection mechanism to resolve instance of ReactiveMongoApi which as an interface to MongoDB.
The base class ReactiveMongoApiFromContext is also available to help implementing custom provisioning/loading (e.g. for application loader).
In your Play application, you can use ReactiveMongo with multiple connection pools (possibly with different replica sets and/or different options), using the @NamedDatabase annotation.
Consider the following configuration, with several connection URIs.
Then the dependency injection can select the API instances using the names.
Configure your database access
This module reads the connection properties from the application.conf and gives you an easy access to the connected database.
You can use the URI syntax to point to your MongoDB:
This is especially helpful on platforms like Heroku, where the add-ons publish the connection URI in a single environment variable. The URI syntax supports the following format: mongodb://[username:password@]host1[:port1][,hostN[:portN]]/dbName?option1=value1&option2=value2
A more complete example:
To configure a connection pool different from the default one (for the @NamedDatabase annotation), the key must be mongodb.ANY_NAME.uri.
The setting mongodb.connection.strictUri (true or false) can be added to the Play configuration (or mongodb.ANY_NAME.connection.strictUri for a connection pool other than the default one), to enforce the ReactiveMongo only accepts strict URI: to make the connection pool throws an exception if given an URI with unsupported options.
By default (false), unsupported options (e.g. ?foo=bar) are just ignored.
Configure underlying Akka system
ReactiveMongo loads its Akka configuration from the key mongo-async-driver.
To change the corresponding log level (prevent dead-letter logging for example):
The BSON types can be used in the bindings of the Play routing.
For example, consider an action as follows.
This action can be configured with a BSONObjectID binding, in the conf/routes file.
GET /foo/:id controllers.Application.foo(id: reactivemongo.bson.BSONObjectID)
When using BSON types in the route bindings, the Play plugin for SBT must also be set up (in your build.sbt or project/Build.scala), to be able to install the appropriate import in the generated routes.
If this routes import is not configured, errors as following will occur.
[error] /path/to/conf/routes:19: No URL path binder found for type reactivemongo.bson.BSONObjectID. Try to implement an implicit PathBindable for this type.
Once this is properly set up, any BSON types can be used in your routes, and the appropriate validations are used.
In the current example with BSONObjectID, if calling /foo/bar (with bar bound as :id), then the error thereafter will be raised.
For request 'GET /foo/bar' [wrong ObjectId: 'bar']
Helpers for GridFS
Play2-ReactiveMongo makes it easy to serve and store files in a complete non-blocking manner.
It provides a body parser for handling file uploads, and a method to serve files from a GridFS store.
The maximum size of upload using the GridFS provided by a MongoController can be configured by the Play DefaultMaxDiskLength.
Play controller sample
Your controller may extend MongoController which provides a few helpers.
All actions are asynchronous, which means ReactiveMongo returns Future[Result].
We use a specialized collection called JSONCollection that deals naturally with JsValue and JsObject.
Play controller sample using JSON Writes and Reads
First, the models:
The following import is recommended to make sure JSON/BSON conversions are available.
Then, the controller which uses the ability of the JSONCollection to handle JSON’s Reads and Writes:
For Play > 2.4, if you still have a file conf/play.plugins, it’s important to make sure this file no longer mentions ReactiveMongoPlugin, which is replaced by ReactiveMongoModule. With such deprecated configuration, the following error can be raised.
ConfigurationException: Guice configuration errors:
1) Could not find a suitable constructor in
As in the code driver, the database resolution has been updated in the Play module. If using the deprecated resolution, the following warning is raised by the compiler.
method db in trait MongoController is deprecated: Use [[database]]
A related warning can also be displayed about GridFS usage.
method gridFSBodyParser in trait MongoController is deprecated: Use gridFSBodyParser with Future[GridFS]
Full Web Application featuring basic CRUD operations and GridFS streaming: online demo / source