In groovy updater script, the originally expected behavior was to configure either xpath or query for node iteration and so the updater engine is able to calculate the update count to commit or refresh the batch.
However, in practice, sometimes we have used a query to get a root node for example and done many node updates, which doesn't affect the internal update count. You can even find that kind of examples in our online documentation .
This might be okay for small updates, but if the updates (which is not synchronized with internal updateCount of the updater engine) are bigger (e.g, 100 or 1000), then it might be problematic in reality, causing OOME potentially. For example, what if someone executes a script to create many documents based on text files on the server..
So, to address this issue, I ended up thinking about the option to feedback the updater engine with updated/skipped/failed count in BaseNodeUpdateVisitor implementations.
For example, maybe BaseNodeUpdateVisitor can have an additional property, visitorContext (similarly to parametersMap). Then whenever it updates nodes from manual node retrievals, the script may invoke visitorContext.reportUpdated(path), which adds up the internal updateCount for instance, which helps consistent/aligned batch commit/discard behavior.
What do you think?