This conversation is starting to get a bit complex, so I'll try to organize my answers: # Applying the same solution to HV and HSearch @Emmanuel: right, I didn't see you were also talking about HV. I was only considering the HSearch case. I think I agree with you both, HV and HSearch are a bit different and we certainly cannot share the whole code. Some principles could probably be shared, such as the abstraction over accessing the input type with Emmanuel's "StructureTraverser". But the traversal algorithms are probably very different. And in fact, these traversals are at the core of each project's purpose, so it may not be a good idea to try to make them "more similar". # The requirements for HSearch @Emmanuel: we didn't take much notes, but we did draw a diagram of the target architecture: https://drive.google.com/a/redhat.com/file/d/0B_z-zSf_hJiZam JkZFBlNG5CeDQ/view?usp=sharing When you shared your recordings/pictures, I asked for the write permission on the shared folder to put the diagram, but you probably haven't had time yet. If I remember correctly, here were the main requirements: - Separate the source data traversal from the actual output format. - This will help when implementing different indexing services (Elasticsearch, Solr): we don't want to assume anything about the target format. - Make the implementation of JGroups/JMS as simple as possible. - In these case, we don't really want to build documents, we just want to transform the entity to a serializable object, and reduce the information to transmit over the network to a minimum. - Ideally, we'd just want to "record" the output of the traversal, transmit this recording to the master node, and leave the master node replay it to build a document. This would have the added benefit of not requiring any knowledge of the underlying technology (Lucene/ES/Solr) on the client side. - Requirements on the "mapping tree" (I'm not absolutely sure about those, Sanne may want to clarify): - “depth” and navigational graph to be pre-computed: tree of valid fields and options to be known in advance. - Immutable, threadsafe, easy to inspect/walk mapping tree - And on my end (I think Sanne shared this concern, but I may be wrong): query metadata as little as possible at runtime. # More info on my snippet @Gunnar: you asked for some client code, but I'm not sure it'll be very explicit. The only client-facing interface (as far as document building goes) is EntityDocumentConverter. So, the parts of the application that need to convert an entity to a document will do something like that: EntityDocumentConverter<E, D> converter = indexManager.getEntityDocument Converter(); D document = converter.convert( entity ); indexManager.performOperation( newAddOperation( document ) ); The idea behind this was to make runtime code as simple as possible, and move the complexity to the bootstrapping. Basically, when you call converter.convert, it will delegate to ValueProcessors, which will extract information from the entity and inject it into the DocumentBuilder. What is extracted, and how to extract it, is completely up to the ValueProcessor. This means that, when bootstrapping, a tree of ValueProcessors will be built according to the metadata. For instance when a @Field is encountered, we build an appropriate ValueProcessor (potentially nesting multiple ones if we want to keep matters separate: one for extracting the property's value, one for transforming this value using a bridge). When an @IndexedEmbedded is encountered, we build a different ValueProcessor. And so on. Here is an (admittedly very simple) example of what it'd look like in the metadata processor; List<ValueProcessor> collectedProcessors = new ArrayList<>(); for ( XProperty property : properties ) { Field fieldAnnotation = property.getAnnotation( Field.class ); if ( fieldAnnotation != null ) { ValueProcessor fieldBridgeProcessor = createFieldBridgeProcessor( property.getType(), fieldAnnotation ); ValueProcessor propertyProcessor = new JavaPropertyProcessor( property, fieldBridgeProcessor ); // The value of the property will be passed to the fieldBridgeProcessor at runtime collectedProcessor.add( propertyProcessor ); } } ValueProcessor rootProcessor = new CompositeProcessor( collectedProcessors ); return new EntityDocumentConverter( rootProcessor, indexManagerType.getDocumentBuilder() ) The actual code will obviously be more complex, first because we need to support much more features than just @Field, but also because the createFieldBridgeProcessor() method needs to somehow build backend-specific metadata based on the nature of the field. But I think the snippet captures the spirit. # Summary Thinking about it a little, there's a different focus in our solutions. 1. Emmanuel's solutions focuses on abstracting over the input data format (thanks to StructureTraverser), assuming the traversal algorithm will be re-implemented for each output type. 2. My solution focuses on abstracting over the output data format (thanks to DocumentBuilder), assuming the traversal algorithm will be re-implemented for each input type using different ValueProcessors. 3. Gunnar's solution seem to focus on abstracting over the output data format, reimplementing the traversal algorithm for each input type using a different TreeTraversalSequence. Solution 1 and 2 are, in my opinion, compatible. We could have very generic ValueProcessors that would make use of a StructureTraverser to extract data and of a DocumentBuilder to inject it into a document. I'm not sure it is necessary, because I expect metadata to be defined differently based on the input type, and hence the traversal algorithms to be slightly different, but I think we could do it. About solution 3: TreeTraversalSequence seems to implement the traversal algorithm, while TreeTraversalEventConsumer abstracts over the output format and TreeTraversalEvent abstracts over the information being transferred. I think the general principles are more or less equivalent to solution 2. The main difference are: - How the context around the data to transfer is propagated. In solution 2, we pass the context progressively by making call to the DocumentBuilder (documentBuilder.nest(...), documentBuilder.addField(...)). In solution 3, the context is explicitly modeled as a TreeTraversalEvent. - How metadata is looked up. In solution 2, the metadata is built in the objects implementing the traversal algorithm, so there is no look up to speak of. In solution 3, there is a metadata lookup for each node in the tree. Maybe there's a matter of performance, but I don't know enough about this to give a definitive answer. In the end it's probably more a matter of taste. Yoann Rodière <yoann(a)hibernate.org&gt; Hibernate NoORM Team On 7 February 2017 at 11:17, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: