{"id":712,"date":"2011-11-03T19:27:00","date_gmt":"2011-11-03T19:27:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/using-mongodb-with-morphia.html"},"modified":"2012-10-21T20:43:56","modified_gmt":"2012-10-21T20:43:56","slug":"using-mongodb-with-morphia","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/11\/using-mongodb-with-morphia.html","title":{"rendered":"Using MongoDB with Morphia"},"content":{"rendered":"
In the past few years, NoSQL<\/a> databases like CouchDB, Cassandra and MongoDB have gained some popularity for applications that don\u2019t require the semantics and overhead of running a traditional RDBMS. I won\u2019t get into the design decisions to go into choosing a NoSQL database as others have done a good enough job already, but I will relate my experience with MongoDB and some tricks on using it effectively in Java.<\/p>\n

I recently have had a chance to work with MongoDB<\/a> (as in humongoous), which is a document-oriented database written in C++. It is ideal for storing documents which may vary in structure, and it uses a format similar to JSON, which means it supports similar data types and structures as JSON. It provides a rich yet simple query language and still allows us to index key fields for fast retrieval. Documents are stored in collections which effectively limit the scope of a query, but there is really no limitation on the types of heterogeneous data that you can store in a collection. The MongoDB site<\/a> has decent docs if you need to learn the basics of MongoDB.<\/p>\n

MongoDB in Java<\/span><\/p>\n

The Mongo Java driver basically exposes all documents as key-value pairs exposed as map, and lists of values. This means that if we have to store or retrieve documents in Java, we will have to do some mapping of our POJOs to that map interface. Below is an example of the type of code we would normally have to write to save a document to MongoDB from Java:<\/p>\n

BasicDBObject doc = new BasicDBObject();\r\n\r\ndoc.put(\"user\", \"carfey\");\r\n\r\nBasicDBObject post1 = new BasicDBObject();\r\npost1.put(\"subject\", \"spam & eggs\");\r\npost1.put(\"message\", \"first!\");\r\n\r\nBasicDBObject post2 = new BasicDBObject();\r\npost2.put(\"subject\", \"sorry about the spam\");\r\n\r\ndoc.put(\"posts\", Arrays.asList(post1, post2));\r\n\r\ncoll.insert(doc);\r\n<\/pre>\n
This is fine for some use cases, but for others, it would be better to have a library to do the grunt work for us.<\/p>\n
Enter Morphia<\/span><\/p>\n
Morphia<\/a> is a Java library which acts sort of like an ORM for MongoDB \u2013 it allows us to seamlessly map Java objects to the MongoDB datastore. It uses annotations to indicate which collection a class is stored in, and even supports polymorphic collections. One of the nicest features is that it can be used to automatically index your collections based on your collection- or property-level annotations. This greatly simplifies deployment and rolling out changes.<\/p>\n
I mentioned polymorphic storage of multiple types in the same collection. This can help us map varying document structures and acts somewhat like a discriminator<\/a> in something like Hibernate.
 
<\/div> <\/div><\/p>\n
Here\u2019s an example of how to define entities which will support polymorphic storage and querying. The Return class is a child of Order and references the same collection-name. Morphia will automatically handle the polymorphism when querying or storing data. You would pretty much do the same thing for annotating collections that aren\u2019t polymorphic, but you wouldn\u2019t have multiple classes using the same collection name.<\/p>\n
Note:<\/span> This isn\u2019t really an example of the type of data I would recommend storing in MongoDB since it is more suited to a traditional RDBMS, but it demonstrates the principles nicely.<\/p>\n
@Entity(\"orders\") \/\/ store in the orders collection\r\n@Indexes({ @Index(\"-createdDate, cancelled\") }) \/\/ multi-column index\r\npublic class Order {\r\n    @Id private ObjectId id; \/\/ always required\r\n\r\n    @Indexed\r\n    private String orderId;\r\n\r\n    @Embedded \/\/ let's us embed a complex object\r\n    private Person person;\r\n    @Embedded\r\n    private List<Item> items;\r\n\r\n    private Date createdDate;\r\n    private boolean cancelled;\r\n\r\n    \/\/ .. getters and setters aren't strictly required\r\n    \/\/ for mapping, but they would be here\r\n}\r\n\r\n@Entity(\"orders\") \/\/ note the same collection name\r\npublic class Return extends Order {\r\n    \/\/ maintain legacy name but name it nicely in mongodb\r\n    @Indexed\r\n    @Property(\"rmaNumber\") private String rma;\r\n    private Date approvedDate;\r\n    private Date returnDate;\r\n}\r\n<\/pre>\n
Now, below I will demonstrate how to query those polymorphic instances. Note that we don\u2019t have to do anything special when storing the data. MongoDB stores a className attribute along with the document so it can support polymorphic fetches and queries. Following the example above, I can query for all order types by doing the following:<\/p>\n
\/\/ ds is a Datastore instance\r\nQuery<Order> q = ds.createQuery(Order.class).filter(\"createdDate >=\", date);\r\nList<Order> ordersAndReturns = q.asList();\r\n\r\n\/\/ and returns only\r\nQuery<Return> rq = ds.createQuery(Return.class).filter(\"createdDate >=\", date);\r\nList<Return> returnsOnly = rq.asList();\r\n<\/pre>\n
If I only want to query plain orders, I would have to use a className filter as follows. This allows us to effectively disable the polymorphic behaviour and limit results to a single target type.<\/p>\n
Query<Order> q = ds.createQuery(Order.class)\r\n    .filter(\"createdDate >=\", cutOffDate)\r\n    .filter(\"className\", Order.class.getName());\r\n\r\nList<Order> ordersOnly = q.asList();\r\n<\/pre>\n
Morphia currently uses the className attribute to filter results, but at some point in the future is likely to use a discriminator column, in which case you may have to filter on that value instead.<\/p>\n
Note:<\/span> At some point during startup of your application, you need to register your mapped classes so they can be used by Morphia. See here for full details<\/a>. A quick example is below.<\/p>\n
Morphia m = ...\r\nDatastore ds = ...\r\n\r\nm.map(MyEntity.class);\r\nds.ensureIndexes(); \/\/creates all defined with @Indexed\r\nds.ensureCaps(); \/\/creates all collections for @Entity(cap=@CappedAt(...))\r\n<\/pre>\n
Problems with Varying Structure in Documents<\/span><\/p>\n
One of the nice features of document-oriented storage in MongoDB is that it allows you to store documents with different structure in the same collection, but still perform structured queries and index values to get good performance.<\/p>\n
Morphia unfortunately doesn\u2019t really like this as it is meant to map all stored attributes to known POJO fields. There are currently two ways I\u2019ve found that let us deal with this.<\/p>\n
The first is disabling validation on queries. This will mean that values which exist in the datastore but can\u2019t be mapped to our POJOs will be dropped rather than blowing up:<\/p>\n
\/\/ drop unmapped fields quietly\r\nQuery<Order> q = ds.createQuery(Order.class).disableValidation();\r\n<\/pre>\n
The other option is to store all unstructured content under a single bucket element using a Map. This could contain any basic types supported by the MongoDB driver including Lists and Maps, but no complex objects unless you have registered converters with Morphia (e.g. morphia.getMapper().getConverters().addConverter(new MyCustomTypeConverter()) . <\/p>\n
@Entity(\"orders\")\r\npublic class Order {\r\n    \/\/ .. our base attributes here\r\n    private Map<String, Object> attributes; \/\/ bucket for everything else (\r\n}\r\n<\/pre>\n
Note that Morphia may complain on startup that it can\u2019t validate the field (since the generics declaration is not strict), but as of the current release version (0.99), it will work with no problem and store any attributes normally and retrieve them as maps and lists of values.<\/p>\n
Note: When it populates a loosely-typed map from a retrieved document, it will use the basic MongoDB Java driver types BasicDBObject and BasicDBList. These implement Map and List respectively, so they will work pretty much as you expect, except that they will not be equals() to any input maps or lists you may have stored, even if the structure and content appear to be equal. If you want to avoid this, you can use the @PostLoad annotation to annotate a method which can perform normalization to JDK maps and lists after the document is loaded. I personally did this to ensure we always see a consistent view of MongoDB documents whether they are pulled from a collection or not yet persisted. <\/p>\n
Reference: <\/i><\/strong>Using MongoDB with Morphia<\/a> from our JCG partner<\/a>s at the Carfey Software blog<\/a>. <\/p>\n
Related Articles :<\/i><\/strong><\/p>\n