OAK-12010 Simplified index management (without optimizer)#2689
OAK-12010 Simplified index management (without optimizer)#2689thomasmueller wants to merge 15 commits intotrunkfrom
Conversation
bhabegger
left a comment
There was a problem hiding this comment.
Nice clean work 👍
I like the test coverage and the comments among the rest !
I don't see anything blocking and just have a few comments/suggestions.
| if (!diffContent.exists()) { | ||
| continue; | ||
| } | ||
| PropertyState lastMod = diffContent.getProperty("jcr:lastModified"); |
There was a problem hiding this comment.
Is there not a constant definition for this type of "well-known" entries ? (same for :lastProcessed, jcr:data, /oak:index/, etc.)
In my opinion this helps a lot to understand, identify in one go what are the 'system' properties, paths, etc., and know where they are used. But also have them documented in the code base as javadoc.
(Not a blocker, just a curiosity 😉)
There was a problem hiding this comment.
There probably is. I agree we are not consistently using these constants, so there is a risk of typos.
There was a problem hiding this comment.
I used constants now where available, and did add new ones where I think it is useful (which -- granted -- is subjective).
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/diff/DiffIndex.java
Outdated
Show resolved
Hide resolved
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/diff/DiffIndex.java
Outdated
Show resolved
Hide resolved
| * @param store the node store | ||
| * @param indexDefinitions the /oak:index node | ||
| */ | ||
| public static void applyDiffIndexChanges(NodeStore store, NodeBuilder indexDefinitions) { |
There was a problem hiding this comment.
To ease readability maybe we could split this method in :
- parsing entries
- diffing entries
and delegate the orchestration to a caller method ?
There was a problem hiding this comment.
I now split it into two parts that I think make sense.
| JsonObject repositoryDefinitions = RootIndexesListService.getRootIndexDefinitions(indexDefinitions); | ||
| LOG.debug("Index list {}", repositoryDefinitions.toString()); | ||
| try { | ||
| DiffIndexMerger.instance().merge(newImageLuceneDefinitions, repositoryDefinitions, store); |
There was a problem hiding this comment.
merge also seams to do something with diff.index and diff.index.optimizer couldn't we call the mergeDiff directly instead (without a dependency to the NodeStore)?
There was a problem hiding this comment.
We want to re-use the "merge" feature in another project (when processing diffs that are sent via script, so come from external sources). So it's better to keep DiffIndexMerger#merge
|
|
||
| // merge | ||
| JsonObject merged = null; | ||
| if (indexDiff == null) { |
There was a problem hiding this comment.
As an example, maybe this premerge null checking logic could be moved down into the processMerge itself ? (The "nothing to do" case could be handled by a null or Optional merged result)
There was a problem hiding this comment.
There is some code executed in this case (latestCustomized == null...) so that would require changing processMerge, which I would avoid.
There was a problem hiding this comment.
if (indexDiff == null) {
// no diff definition: use to the OOTB index
if (latestCustomized == null) {
log("Only a product index found, nothing to do");
return false;
}
merged = latestProductIndex;
} else {
merged = processMerge(latestProductIndex, indexDiff);
}
Could be rewritten:
if(indexDiff == null && latestCustomized == null) {
log("Only a product index found, nothing to do");
return false;
}
merged = processMerge(latestProductIndex, indexDiff);
with processMerge returning latestProductIndex if indexDiff is null.
we could even let it return null if both are null and exit fast if merged is null with the log.
There was a problem hiding this comment.
Well it would move part of the logic to processMerge, which I would like to avoid. Also, the comment is lost.
| * | ||
| * "null" entries are not supported. | ||
| */ | ||
| public class JsonNodeBuilder { |
There was a problem hiding this comment.
The Builder in the name could be misleading as, unless I missed something. this class doesn't seem to follow the "Builder" pattern, and seams more like a Helper class (but then there are different style tastes out their).
There was a problem hiding this comment.
Right... It's a converter from "Json" to "NodeBuilder". It's confusing.
What about JsonNodeWriter, or JsonToNodeConverter?
There was a problem hiding this comment.
I would prefer Converter among the two as Writer is quite connotated (PrintWriter, StringWriter, etc.). However, both Writer and Converter still suggests some sort of instantiation and don't highlight that this class is a utility class.
There was a problem hiding this comment.
JsonNodeConversionUtil ?
JsonNodeConversionHelper ?
There was a problem hiding this comment.
Hm, it's not really a converter... the nodes are persisted in Oak, and "converter" (for me) would imply that the nodes are just converted and the result is returned.
It's mostly about creating, and possibly updating and deleting, nodes... So what about:
- JsonNodeSmith (recommended by a tool; sounds right to me)
- JsonNodeCreator (because it's mostly about creating new nodes... but not purely)
- JsonNodeWriter, for the case it's updating / deleting (currently, I think it's not, but possibly in the future)
There was a problem hiding this comment.
Ok, then. Writer could pass, because it does I/O even though it's not in the usual sense. JsonNodeSaver ? JsonNodeStorer ? JsonNodeManager ? JsonNodeUpdater ?
I'm not really convinced by any... But maybe it triggers need ideas ? Otherwise just go with your preference.
There was a problem hiding this comment.
Ok, then. Writer could pass, because it does I/O even though it's not in the usual sense. JsonNodeSaver ? JsonNodeStorer ? JsonNodeManager ? JsonNodeUpdater ?
I'm not really convinced by any... But maybe it triggers need ideas ? Otherwise just go with your preference.
There was a problem hiding this comment.
OK so I use JsonNodeUpdater.
| import java.util.ArrayList; | ||
|
|
||
| import org.apache.felix.inventory.Format; | ||
| import org.apache.jackrabbit.oak.commons.json.JsonObject; |
There was a problem hiding this comment.
I'm guessing that OAK has it's own JSON processing library for historical reasons ?
| + " } }"); | ||
|
|
||
| repositoryDefinitions = RootIndexesListService.getRootIndexDefinitions(store, "lucene"); | ||
| assertSameJson("{\n" |
There was a problem hiding this comment.
It's a shame Java 11 is a bit too early for text blocks :)
There was a problem hiding this comment.
I agree (btw. text blocks are not "raw" and still need escaping).
But I think it's readable as is.
| public void createDummy() { | ||
| // when enabling "deleteCreatesDummyIndex", then a dummy index is created | ||
| // (that indexes /dummy, which doesn't exist) | ||
| String merged = new DiffIndexMerger(new String[0], true, true, false).processMerge(JsonObject.fromJson("{}" |
There was a problem hiding this comment.
Which true is it ?
| String merged = new DiffIndexMerger(new String[0], true, true, false).processMerge(JsonObject.fromJson("{}" | |
| boolean deleteCreatesDummyIndex = true; | |
| String merged = new DiffIndexMerger(new String[0], deleteCreatesDummyIndex, true, false).processMerge(JsonObject.fromJson("{}" |
Would make it explicit
There was a problem hiding this comment.
Hm, "list of boolean flags" is not user friendly... thinking about an alternative.
There was a problem hiding this comment.
I added setters (there no real harm to not have the fields final in this case). Sure we could also add a Builder. Or a Factory, or AdapterFactoryBuilder... :-)
…/diff/DiffIndex.java Co-authored-by: Benjamin Habegger <benjamin@habegger.tech>
…/diff/DiffIndex.java Co-authored-by: Benjamin Habegger <benjamin@habegger.tech>
amit-jain
left a comment
There was a problem hiding this comment.
Overall looks good to me!!
A few minor suggestions added.
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/diff/DiffIndex.java
Outdated
Show resolved
Hide resolved
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/IndexName.java
Outdated
Show resolved
Hide resolved
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/diff/DiffIndexMerger.java
Outdated
Show resolved
Hide resolved
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/diff/DiffIndexMerger.java
Outdated
Show resolved
Hide resolved
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/diff/DiffIndex.java
Outdated
Show resolved
Hide resolved
| * (input) | ||
| * @return whether a new version of an index was added | ||
| */ | ||
| public boolean processMerge(String indexName, JsonObject indexDiff, JsonObject newImageLuceneDefinitions, JsonObject combined) { |
There was a problem hiding this comment.
yes recommend breaking this method, example (from comments)
- findLatestVersions
- performMerge
- isChanged
- addMetadata
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/diff/DiffIndex.java
Outdated
Show resolved
Hide resolved
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/diff/JsonNodeBuilder.java
Outdated
Show resolved
Hide resolved
…/diff/DiffIndex.java Co-authored-by: Amit Jain <amitj@apache.org>
…/diff/DiffIndexMerger.java Co-authored-by: Amit Jain <amitj@apache.org>
…/diff/DiffIndex.java Co-authored-by: Amit Jain <amitj@apache.org>
…/diff/JsonNodeBuilder.java Co-authored-by: Benjamin Habegger <benjamin@habegger.tech>
…/diff/DiffIndex.java Co-authored-by: Amit Jain <amitj@apache.org>
|



This is a subset of the (much) larger draft PR #2652
This is just support for the "diff.index"; without the optimizer.