We use Solr for storing different types structured data. Solr works fine and feels intuitive to use as long as structured entity has all properties of basic types like string, number, date etc. But the moment we like to index an entity with relations (which is quite common), intuitiveness of the response will need to be compromised with. Some teams have different strategy to take care of this. We have tried different approaches and settled with a custom response writer along with a naming convention in schema. Yes, those who has to work with dynamic schema or schemaless, following wont help.
To explain better, I will take small and well-known entity as example : Employee 🙂 . Lets say following is the structure of our entity
- Date of Joining
Object Address and Projects are nested objects. Compare following two json structures – traditional approach of storing vs more intuitive json for consumers (solr response) would look like below :
| Solr default flat structure response
|| Intuitive nested json response
So the goal is to get response look like second one.
Initially we started using custom response writer which makes use of velocity to render response like above. But it’s not intuitive during querying.
Ex : If we want to find all people in city, chennai :
Where as in response it goes like an object. It will be more confusing when we have more levels.
Final Solution :
Solution is a combination of naming convention and custom response writer.
Naming convention to following which looks like typical dot notation for accessing properties. Every field name should follow dot convention for sub-fields/properties. For example Address object has a street, it should look like this address.street. So with this field names for our example would look like :
Custom response writer which converts flat structure into hierarchical based on field name. This is more like normal json writer available, except it groups fields and creates a json object if field name has “.” in its name. As dot notations are quite familiar to any developer, queries also look intuitive.
Ex : again to find people from same city :
There could be many other ways to achieve same but we found this more intuitive and effective to use. Any suggestions and other ideas please share.