bhabegger commented on code in PR #3078:
URL: https://github.com/apache/jackrabbit-oak/pull/3078#discussion_r3813211141
##########
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/inventory/IndexDefinitionPrinter.java:
##########
@@ -69,6 +74,17 @@ public void print(PrintWriter printWriter, Format format,
boolean isZip) {
NodeState idxState = NodeStateUtils.getNode(root, indexPath);
createSerializer(json).serialize(idxState);
}
+ // The "diff" indexes (diff.index / diff.index.optimizer) are not
oak:QueryIndexDefinition nodes, so they
+ // are not returned by the IndexPathService and would otherwise be
missing from the output. Add them
+ // explicitly, rendering their diff.json payload as inline JSON so
the pending diff is readable.
+ for (String name : new String[] {DiffIndexMerger.DIFF_INDEX,
DiffIndexMerger.DIFF_INDEX_OPTIMIZER}) {
Review Comment:
When I see this kind of "work around", it very often means there is a design
flaw somewhere. It's likely not the issue of this PR, but something else (the
complexity of this PR is a symptom).
Before `/oak:index/` contained a single type of object
`oak:QueryIndexDefinition`. Now it can contain 2 types of objects
`oak:QueryIndexDefinition` and these `diff.index` or `diff.index.optimizer` for
those 2 it's not the type that is important but there name.
Before, printing was a natural walk through the tree outputting what ever
was on it's path.
Maybe we can make this "printing" a bit cleaner by splitting this method up:
loop on the indexPathService.getIndexPaths() -> call a auxilary
"printIndexDefinitionNode" mtehod for this path
Move the logic to determine which diffIndexPaths to the indexPathService
(where we add a method .getDiffPaths())
loop on those results and internally call an auxilary "printDiffNode" method
(which is basically serializeDiffIndex, see my comments there).
##########
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/inventory/IndexDefinitionPrinter.java:
##########
@@ -81,4 +97,44 @@ public void setFilter(String filter) {
private JsonSerializer createSerializer(JsopBuilder json) {
return new JsonSerializer(json, filter, new Base64BlobSerializer());
}
+
+ /**
+ * Serialize a diff index node, inlining its {@code diff.json} payload as
JSON. All other file child nodes are
+ * rendered as base64 blobs, for backward compatibility.
+ */
+ private void serializeDiffIndex(JsopBuilder json, NodeState idxState) {
+ json.object();
Review Comment:
I don't like so much that we have walking logic in this class and them more
walking logic in the serializer class.
The role of this class is to delegate to JsonSerializer (which consists in
walking a NodeState and outputting in JSON what it finds). So it does the
walking... we shouldn't be doing it here. Why are we doing it here ? Because we
want a special processing of a certain parts : the inlining of the diff.json
file object. Why don't we just update the serializer (eventually with a config)
to add inlining of certain nodes and the configure the serializer with that
option here ?
Here we would not need the 2 extra loops as this would be taken care of by
the serializer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
