Orchestrate to Mongo: Pt. 2

Well I’m happy to say that this Java stuff is witchcraft.  The project I had been given was a Java application with Spring Data as the core interface to the Orchestrate Data.  Moving to Mongodb, which is also supported natively by Spring, was a pretty painless endeavor.

 

I won’t go into all of the details but I was able to essentially add the mongodb spring-data dependencies o the maven POM for this project and rip the Orchestrate band-aid off.  From there it was almost, but not completely a matter of replacing any reference to Orchestrate with the reference to Mongo instead.  The biggest pain point was that local and dev environments were using mocked out instances of Orchestrate instead of live collections.  After putting a real mongodb in each environment I was pretty close to passing all of the unit and acceptance tests.  There were some autowired beans that had to be added to the local and dev environments since they were no longer mocked.  After that it was pretty smooth sailing thought the project.   In the end there were only data format issues to work through and one acceptance test that wouldn’t pass.  The senior java guys feel like it was a scoping issue for one of the test dependencies, but nothing we tried would fix it.  In the end we ripped out that one test and moved on.  Given the terribly short window left to test and deploy to production it’s an issue that can go on our backlog and we’ll fix it if it looks like a test that really should be done.