Over a million developers have joined DZone.

From Hibernate to MongoDB - Part 2

DZone's Guide to

From Hibernate to MongoDB - Part 2

· Java Zone ·
Free Resource

Secure your Java app or API service quickly and easily with Okta's user authentication and authorization libraries. Developer accounts are free forever. Try Okta Instead.

For those who are interested, I still don't have any large dataset results.
I spent some more time with the datanucleus MongoDB product but I had some issues that they didn't take care of, so I decided not to use them (sorry datanucleus folks, but I'm used to getting support from the community). So I started another approach with EclipseLink, which has JPA/Mongo support too.

Let me say, it was a whole lot more work than I expected it to be. EclipseLink has a different understanding of the JPA annotations, which caused some boring refactorings in the domain model. Fetch was the main problem. Eager doesn't work with MongoDB, and I found that ManyToOne(optional=false) doesn't work either. I have a bugzilla open for this one.

The hardest work was making  EclipseLink play with Spring DM and Gemini JPA. I had some issues with the latest Spring release's AOP stuff, which didn't play with the OSGi classloading anymore, so I went back to 3.0.5, which I knew was working. Then I created a FactoryBean based on the Gemini JPA EntityManagerFactoryBuilder service so that I could still use my Spring managed transactions.

One word to the Gemini folks: Bundle start order is not what OSGi suggests. But restarting a Blueprint/Spring powered bundle (that's what Gemini JPA does for weaving the entity classes) when their appContext isn't finished yet gives you an explosion of exceptions. By the way, I am still running on Spring DM 1.2 because the namespace handler resolving is still a mess in Blueprint. Just my two cents.

In between, I did some clean up work (pay your debts) that still needs some polishing, as there was not enough time to pull through all the changes, so there are some compile errors now. But nothing evil.

One thing to say is that I have some logic that needs a complete restructruring, as there were many queries based on relational thinking that don't work anymore since  EclipseLink/Mongo doesn't support joining. Even if it did, MongoDB gives you a different persistence model and it makes sense to work with larger objects than it did with the relational model.

I have created plenty of tasks that still need to be done, I'm far away from starting to implement mutli-tenancy (which of course is the reason for all of this).

Up until now I spent around about 40 hours on this (remember the domain model is about 70 classes, that are fine now). Of my 20 DAO classes there are three left to restructure that depended too heavily on the relational stuff. All the other stuff is working.

Load time is blazing fast now, most of the time goes into the RAP UI code creating the editors. I guess this will be my new bottleneck :)

My overall impression is that this is still young stuff. Regarding EclipseLink /Mongo, most of the important things work, but things that don't work always throw completely insane errors, forcing you to dive into the code to understand what has gone wrong. For example, when there's a join in the query, a ClassCastException is thrown that says DatabasePlatform cannot be cast to MongoPlatform.  EclipseLink folks, there is plenty of work to be done in there, but overall I am confident today that I can build my (non-profit:) business on it.

Secure your Java app or API service quickly and easily with Okta's user authentication and authorization libraries. Developer accounts are free forever. Try Okta Instead.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}