> 14. mar. 2018 kl. 15:45 skrev Anshum Gupta <ans...@anshumgupta.net>: > > Hi Jan, > > The way I remember it was done (or at least we did it) is by storing the > depth information as a field in the document using an update request > processor and using a custom transformer to reconstruct the original > multi-level document from it.
Right, you either have to store pointer to parent or a depth info. If you only have depth (1, 2, 3) it will not be possible to reconstruct a complex document with multiple child docs each having grandchildren? I found this code in AddUpdateCommand.iterator() <https://github.com/apache/lucene-solr/blob/c50806824005b979a7e4854af38b2d8071bc52c0/solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java#L188>: return new Iterator<Document>() { Iterator<SolrInputDocument> iter; { List<SolrInputDocument> all = flatten(solrDoc); String idField = getHashableId(); boolean isVersion = version != 0; for (SolrInputDocument sdoc : all) { sdoc.setField(IndexSchema.ROOT_FIELD_NAME, idField); if(isVersion) sdoc.setField(CommonParams.VERSION_FIELD, version); // TODO: if possible concurrent modification exception (if SolrInputDocument not cloned and is being forwarded to replicas) // then we could add this field to the generated lucene document instead. } iter = all.iterator(); } It recursively finds all child docs and turns it into an iterator, adding a pointer to root in all children. Guess it would be possible to rewrite this part to add a _parent_ field as well? That would lay the foundation for rewriting [child] transformer to reconstruct grandchildren? Jan
