Play! NoSQL (Building NoSQL applications with Play framework)

Accessing Databases with Play! Framework

Play Framework is a high velocity web framework for Java and Scala. It’s built to make application development faster and glitch free.

Play! provides a plugin for managing JDBC connection pools. So, if you’re working with relational databases, all you’ve to do is to define database connector dependencies in its build file, specify connection properties in configuration file, and voila! You’re all set to use data sources with a single line of code. You can configure as many databases as you need. This and many other Play! features are what most of the developers would ever wish for.

…and NoSQL?

However, integrating Play! with NoSQL databases is where it all ends. Any mature NoSQL plugin is yet to be developed. Reason is obvious: These databases are varied and currently lack a common API. This means plugin for all these databases need to be written separately.

There have been efforts like PlayORM. Some people have had success with using Morphia, which nevertheless works with MongoDB only. I haven’t yet tried them but have seen users struggling with using them.

JPA to your rescue

There is a bad news. While Play! provides seamless JPA integration with relational databases, NoSQL support hasn’t arrived yet. Good news is that Kundera – An object-datastore mapping library based on JPA 2.0, can be easily integrated with Play! framework and make it possible to work like charm with databases it currently supports. This article with guide you step-by-step on setting up Play! framework on your machine, create a project and integrate with Kundera to read and write data in Cassandra, one of the most popular NoSQL database in town. However, you’re free to use database of your choice (of course from those supported by Kundera). Read on!

Setting up a Play! project

Download Play!

1. Goto and download latest Play! release ( at the time of this writing). Unzip in a directory of your choice. We’ll refer to uncompressed folder directory as PLAY_HOME.

2. Add PLAY_HOME folder to you PATH environment variable, so that it’s handy when you run play commands from within your project. If you’re using Bash, you can do this by simply appending m like this to user.home/.bashrc

export PATH=$PATH:/home/impadmin/play-2.1.1

3. …and we are done. (detailed instructions are given here).

Create your project

1. Goto to directory where you want to create your project.

2. Create a new project named play-jpa-kundera (or any fancy name you would like to give it):


3. Run command “play” to enter Play! console.

4. You’re free to use any text editor of your choice for writing source code and modifying configuration files. Eclipse settings files can be generated by running command “eclipse”:


5. execute “run” command from Play! console (server is started in development mode)


At this stage, dependency Jars specified in Build.scala and other Play dependencies are downloaded and copied to classpath.

6. Test your application by hitting localhost:9000 in your favorite browser.


7. Congratulations! Your Play! project “play-jpa-kundera” is ready to use. Import this project in eclipse (if you like) and start playing with it. (A detailed instructions for above steps are available here)

Play! with Kundera

Add Kundera dependencies to project/Build.scala

You need to add Kundera dependency jars (which, by the way are available in a maven repository) to your project. Modify your  Build.Scala file under project folder. It should look like this:

import sbt._
import Keys._
import play.Project._

object ApplicationBuild extends Build {
 val appName = "play-jpa-kundera"
 val appVersion = "1.0-SNAPSHOT"

 val appDependencies = Seq(
 "com.impetus.client" % "kundera-cassandra" % "2.5",

val main = play.Project(appName, appVersion, appDependencies).settings(
 //Kundera Public repositories
 ebeanEnabled := false,
 resolvers += "Kundera" at "",
 resolvers += "Riptano" at "",
 resolvers += "Kundera missing" at "",
 resolvers += "Scale 7" at ""

It’s always better to use the most recent release of Kundera.

Caution: javaJdbc app dependency downloads hibernate-entitymanager jar file that interferes with Kundera. Make sure you remove this app dependency which is by default present.

Write persistence.xml

We are now ready to build our persistence code. First step towards that is writing persistence.xml file, which should be put under conf/META-INF folder:

xmlns="" xmlns:xsi=""
 <persistence-unit name="cassandra_pu">
 <property name="kundera.nodes" value="localhost"/>
 <property name="kundera.port" value="9160"/>
 <property name="kundera.keyspace" value="KunderaExamples"/>
 <property name="kundera.dialect" value="cassandra"/>
 <property name="kundera.client.lookup.class" value="com.impetus.client.cassandra.thrift.ThriftClientFactory" />
 <property name="kundera.cache.provider.class" value="com.impetus.kundera.cache.ehcache.EhCacheProvider"/>
 <property name="kundera.cache.config.resource" value="/ehcache-test.xml"/>

Here, model.User is entity class that we’re going to write next.

Create User Entity

Create a User entity class under app/model package:

package model;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Table;

@Table(name = "users", schema = "KunderaExamples@cassandra_pu")
public class User
 private String userId;

 private String firstName;

 private String lastName;

 private String city;

//Getters/ setters/ constructors go here


Write UserController

Now, time to write the class where magic actually happens, UserController for persist/find/update/delete operations. Write this class under app/controller package:

package controllers;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

import model.User;
import play.Play;
import play.mvc.Controller;
import play.mvc.Result;

public class UserController extends Controller
 static EntityManagerFactory emf;

 public static Result persist()
 EntityManager em = getEmf().createEntityManager();

User user = new User();

 return ok("User 0001 record persisted for persistence unit cassandra_pu");

public static Result find()
 EntityManager em = getEmf().createEntityManager();
 User user = em.find(User.class, "0001");
 return ok("Found User in database with the following details:" + printUser(user));

public static Result update()
 EntityManager em = getEmf().createEntityManager();
 User user = em.find(User.class, "0001");
 user.setCity("New York");
 user = em.find(User.class, "0001");
 return ok("Record updated:" + printUser(user));

public static Result delete()
 EntityManager em = getEmf().createEntityManager();
 User user = em.find(User.class, "0001");

 user = em.find(User.class, "0001");
 return ok("Record deleted:" + printUser(user));

private static EntityManagerFactory getEmf()
 if (emf == null)
  emf = Persistence.createEntityManagerFactory("cassandra_pu");
 return emf;

private static String printUser(User user)
 if (user == null)
 return "Record not found";

return "n--------------------------------------------------" + "nuserId:" + user.getUserId() + "nfirstName:"
 + user.getFirstName() + "nlastName:" + user.getLastName() + "ncity:" + user.getCity();

Add controller methods to conf/routes file

We’ll add one URL path for each one of CRUD methods in controller. Add them to your conf/routes file, It should look like this:

# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~

# Map static resources from the /public folder to the /assets URL path

GET /assets/*file"/public", file)

################# User Controller###############

# Persist Operation
GET /persist controllers.UserController.persist()

# Find Operation
GET /find controllers.UserController.find()

# Update Operation
GET /update controllers.UserController.update()

# Delete Operation
GET /delete controllers.UserController.delete()

Make entity classes available at runtime

You can skip this step if you’re running Play! in production mode (by running “play start”). However, If you’re running Play! in development mode, Play! uses its own Classloader that doesn’t read classes from target/scala-2.xx/classes folder. As a result, your User entity won’t be loaded at runtime and Kundera will throw below exception when you try to run application:

com.impetus.kundera.KunderaException: com.impetus.kundera.KunderaException: EntityMetadata should not be null
at com.impetus.kundera.persistence.EntityManagerImpl.persist(
In order to make your entity classes available at run time (in development mode, of course), all you’ve to do is to create jar file out of them and put this jar file into lib folder under project root directory. (create lib folder as it won’t exist by default)

Start Cassandra Server and create schema/ tables

I am assuming you’ve already Cassandra server (or database server you’re working on) setup and running on your machine. If not, refer to their respective documentation.

Now, create schema and tables for User entity to be written to:

impadmin@impetus-D189a:/usr/local/apache-cassandra-1.1.6/bin$ ./cassandra-cli --host localhost --port 9160
Connected to: "Test Cluster" on localhost/9160
Welcome to the Cassandra CLI.
Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.
[default@unknown]create keyspace KunderaExamples;
[default@unknown]use KunderaExamples;
[default@KunderaExamples]create column family users with comparator=UTF8Type and default_validation_class=UTF8Type and key_validation_class=UTF8Type;
Waiting for schema agreement...
... schemas agree across the cluster

Test your application

Now, time to fasten your seat-belts! Run below URLs in your web browser one after other:

1. http://localhost:9000/persist


You can test inserted data from Cassandra-cli


2. http://localhost:9000/find


3. http://localhost:9000/update


4. http://localhost:9000/delete



11 thoughts on “Play! NoSQL (Building NoSQL applications with Play framework)

  1. Hello Thank you so much clear all of my douts about playframework. In the example you had use cassandra i want to know it can be work proper on mysql sir also sir???


  2. Hey, this walkthrough was very helpful (thanks!), but I’ve been having some issues. After running localhost:9000/persist, the new User should be stored in my cassandra database, right? But when I run “list users;” in my cassandra-cli, it says “0 Row Returned”. What’s weird is that, if i run localhost:9000/find, it does find User 0001 and returns the correct information, so the information must be stored somewhere. Do you know what could be going wrong?


      • Could you check whether you are viewing correct cassandra database instance. Are you sure you didn’t hit list after delete, try viewing data from cqlsh console, if nothing works, you may have to debug it with Kundera source


  3. Pingback: Problems accessing Cassandra through Kundera remotely with authorization turned on | BlogoSfera

  4. Very good tutorial! Thank you very much!
    If you want to run with play 2.2.0 you don’t need Build.scala. Just change built.sbt in the following way:

    name := “play-jpa-kundera”

    version := “1.0-SNAPSHOT”

    libraryDependencies ++= Seq(
    “com.impetus.client” % “kundera-cassandra” % “2.5”,


    and plugins.sbt should look this way:

    name := “play-jpa-kundera”

    version := “1.0”

    // Comment to get more information during initialization
    logLevel := Level.Warn

    // The Typesafe repository
    resolvers += “Typesafe repository” at “”,
    resolvers += “Kundera” at “”,
    resolvers += “Riptano” at “”
    resolvers += “Kundera missing” at “”,
    resolvers += “” at “”,
    resolvers += “Scale 7” at “”

    // Use the Play sbt plugin for Play projects
    addSbtPlugin(“” % “sbt-plugin” % “2.2.0”)


  5. sbt.ResolveException: unresolved dependency: javax.persistence#persistence-api;2.0: not found
    [error] unresolved dependency: org.scale7#scale7-pelops;1.3-1.1.x: not found
    [error] unresolved dependency: org.xerial#snappy;1.0.1-rc4: not found

    Always getting this error. Any advices?..


  6. You go through an article about using JPA and NoSQL datastores yet don’t even mention DataNucleus? Really. It was the *first* JPA implementation to support other types of datastores (the ones you term “NoSQL” for example) than what the spec was intended for (RDBMS), and currently supports LDAP, Excel, ODF, XML, JSON, MongoDB, HBase, GAE/J, Cassandra, Neo4j, NeoDatis. It also is a fully compliant JPA implementation for RDBMS (more than Kundera can claim). It additionally supports the more appropriate JDO API, as well as REST. No need to load up different implementations to make use of multiple datastores in your app.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s