Sunday, July 29, 2012

From Hibernate to MongoDB - Part II

For those who are interested, I still don't have any large dataset results.
Last weekend I spent with datanucleus/mongo but I had some issues that noone did seriously take care of, so I decided better not to go that way (Sorry datanucleus folks, but I'm used to get support from the community). This weekend of course 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. Mostly Fetch.Eager doesn't work with mongodb, and some other minor stuff, I found that ManyToOne(optional=false) doesn't work either, have a bugzilla for this one.

But the hardest work was making eclipselink play with spring dm, and gemini jpa. I had some issues with the latest spring release 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 can 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 (thats 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 dm 1.2 because of the namespace handler resolving still is a mess in blueprint. Just my two cents.

Inbetween I did some clean up work (pay your debts) that still needs some polisihing, 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 the relational thinking, that now don't work anymore, as 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 I 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 that).

Up to now I spent round about 40hours on this (remember 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 other stuff is working.

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

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


No comments:

Using Mapstruct with Protobuf3