Mutating documents in-place using a walker/visitor pattern

Data Services
1

Hi,

back in 2020-x it used to be possible to walk documents using the DefaultDocumentWalker, employing a custom DocumentVisitor subclass to mutate the document in-place.

As far as I can tell, these classes no longer exist. Instead, I found the DocumentTreeWalker, which requires another layer of indirection that prevents you from mutating the document directly.

Is there still a way to walk the document and apply mutations in-place?

2

Hi @marcel-calm-dew,

if you are using one of the versions 2020.02 or 2020.06, you should still have access to DefaultDocumentWalker, please be aware that these versions are planned to be retired, hopefully soon.
From version 2020.10 on, we completely changed the api for documents from a tree-like to a plain structure, that’s why there is no need anymore for a walker/visitor pattern, now you have a collection of field-/group-instances which you can manipulate in-place.

3

Hi Gildardo, thanks for getting back to me on this.
At first glance, it seems unfortunate that this possibility is removed.
There are many usecases for us where we need to walk documents in a systematic fashion. E.g. to extract subsections etc. (by throwing data onto a stack as we descend and releasing the stack as we move back up again). In a tree, the structure of the document is reflected logically and you have a sense of scope and context, while in a flat list, there is no such obvious structure grouping together related data.
Maybe it is still possible to process documents in this way, or even a better way, using the new API.

However, I couldn’t find much in the way of documentation on processing/mutating documents server-side.
Could you point me towards some docs/examples for this?

Thanks,
Marcel

4

Hi @marcel-calm-dew,

The code you mentioned has been used only for the creation of index documents from A12 documents for indexing purposes. We have started a different Kernel API to create index documents, therefore there was no longer a need for walkers in our code. We do not want to provide duplicate functionality across our A12 product teams but would rather keep clear boundaries and responsibilities for each team.

5

Hi Tomas, thanks for the feedback. I can see why A12 would decide to do this internally, however, the fact remains that from a project perspective a useful way to interact with A12 documents is more or less being taken away. We used the DocumentWalkers for all sorts of stuff such as test data generation, extracting JSONs, building Excel reporting out of documents etc.

I figured out by now that you can still use the DocumentTreeWalker in conjunction with an IDocument to perform mutations on the IDocument, but it is still more cumbersome than before since you need to hold more state and juggle the model as well as the document. And you cannot operate off the new state inside the walker, of course, since it only reflects the original document state from back when the DocumentTree was created.

6

Hi @marcel-calm-dew, sorry that I did not answer any earlier. We have following services which can help you work with (or find) parts of a document, specially the second one:

  • IDocumentSearchService#getChildren(String, int[])
  • IDocumentSearchService#getDescendants(String, int[])

Regarding mutating documents, you could have a look at:

  • IDocument#addEntityInstance(IEntityInstance)
  • IDocument#removeEntityInstance(IEntityInstance)
  • IFieldInstance#setValue(Object)

While deserializing, you have the option to use the kernel implementations for IDocument, IFieldInstance and so on or to provide your own implementation where you can handle specific situations, see IDocumentFactory. If you decide to provide an own implementation and performance is an issue, you should implement IDocumentIndexed instead of IDocument.

I hope you can go further with this information.

Cheers,
Gil

7

Are there any plans to put this functionality back into A12 or do we have to create a ticket for this?

8

Hi @andreas-fresh-mesa, in kernel there is no plan for the topic “introduce a walker/visitor for documents” at all, if your project does need it, we will need a ticket.