Spring mongo data naming

Mongo Naming

JSON Naming

Google JSON Style Guide

https://publicobject.com/2016/01/20/strict-naming-conventions-are-a-liability/ Gson has built-in magic to convert snakes into camels with its LOWER_CASE_WITH_UNDERSCORES FieldNamingPolicy. We make a global configuration change to our Gson instance and the problem is solved.

Java Naming

Spring data mongo


8.4.3. Property Expressions
Property expressions can refer only to a direct property of the managed entity, as shown in the preceding example. At query creation time, you already make sure that the parsed property is a property of the managed domain class. However, you can also define constraints by traversing nested properties. Consider the following method signature:

List<Person> findByAddressZipCode(ZipCode zipCode);
Assume a Person has an Address with a ZipCode. In that case, the method creates the property traversal x.address.zipCode. The resolution algorithm starts by interpreting the entire part (AddressZipCode) as the property and checks the domain class for a property with that name (uncapitalized). If the algorithm succeeds, it uses that property. If not, the algorithm splits up the source at the camel case parts from the right side into a head and a tail and tries to find the corresponding property — in our example, AddressZip and Code. If the algorithm finds a property with that head, it takes the tail and continues building the tree down from there, splitting the tail up in the way just described. If the first split does not match, the algorithm moves the split point to the left (Address, ZipCode) and continues.

Although this should work for most cases, it is possible for the algorithm to select the wrong property. Suppose the Person class has an addressZip property as well. The algorithm would match in the first split round already, choose the wrong property, and fail (as the type of addressZip probably has no code property).

To resolve this ambiguity you can use \_ inside your method name to manually define traversal points. So our method name would be as follows:

List<Person> findByAddress_ZipCode(ZipCode zipCode);
Because we treat the underscore character as a reserved character, we strongly advise following standard Java naming conventions (that is, not using underscores in property names but using camel case instead).

Mongo References:

Manual references are named after the referenced collection. Use the document type (collection name in singular) followed by _id ( _id ). This is the only case where you can use underscore in the middle. For example, in a dogs collection, a document would have manual references to external documents named like this: { name: 'fido', owner_id: '5358e4249611f4a65e3068ab', race_id: '5358ee549611f4a65e3068ac', colour: 'yellow' ... }


Mongo follows javascript naming convention using camelCase

Mongo has no preference on camelCase v.s. underscore_style just stay consistent with the language. But also be consistent with on-wire json/xml format, also consider for Android/ iOS / Javascript web consumer sides.


different to relational database, in mongoldb, key names are stored in every document, so avoid using long names.


using shorter keys can potentially save a lot of space and even increase performance (after all, more of a smaller database can fit into memory). WiredTiger engine in Mongo 3.0 supports compression, the point is rather moot.