As you mentioned, we have snakeCase related naming strategy set in the application.properties file.
The naming strategy ensures that attributes in camelCase from the POJOs, eg.
questionId will be stored as
question_id in the mongo document, and when that document is read from the database,
question_id will be mapped back to
questionId in the POJO entity. This ensures that entity attributes follow the correct respective naming cases in both Java code and Mongo db. This is applied at the entity level (when POJOs are annotated with
The naming strategy works perfectly when
MongoRepository is being used, since it actually fetches/writes all data wrt the entity POJO.
MongoTemplate is a low level framework which doesn’t take this naming strategy into account, so constructing queries or updates in
MongoTemplate , one would have to use the snake case instead of the camel case.
MongoTemplate by default will return a
Document class, a low level KV mapping (note that keys will be in snake case as they’re read directly from the db). But in
mongoTemplate.find() , if we map it to the entity POJO’s class, it would actually follow the naming strategy and map
MongoTemplate is a very low level framework (used only in special cases or for atomicity purposes). Recommended one to use for db interactions is
MongoRepository , an ODM. Like we had
RestaurantRepository class extending
MongoRepository in QEats, use the similar entity in Buildouts you’ve created to fetch data.