Hello,

In a code base I have been working on for more than a year, we receive JSON 
(as byte[] from queue), we transform JSON, and we persist JSON (to 
Elasticsearch). In the initial design, tempted by its convenience, we made 
the mistake of representing the JSON as java.lang.Object in this JSON 
pipeline. Transformation functions receive Object and spit out Object. 
Though this introduced other problems (e.g., certain types like Set<V> do 
not map 1-to-1 to JSON, variable types do not properly communicate the 
intent of the value, lost caching and object pooling opportunities, etc.) 
revealed themselves in pretty late stages of the development. If I would 
have been starting from scratch today, I would pick Jackson's JsonNode as 
the only allowed JSON type. Though getting off the beaten path might raise 
other issues that we cannot oversee right now and this is where my question 
comes into play.

   1. What are the best practices to represent JSON documents to allow 
   efficient read/write/update operations? (Note that in our case there is no 
   schema, hence no class data binding.)
   2. If one would use JsonNode, what are the best practices for using 
   JsonNodeFactory'ies? A single global factory? A thread-local factory? No 
   factory but explicit JsonNode::new calls?

Thanks in advance.
Best.

-- 
You received this message because you are subscribed to the Google Groups 
"jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to