nfsantos commented on code in PR #667:
URL: https://github.com/apache/jackrabbit-oak/pull/667#discussion_r946892678


##########
oak-search/src/main/java/org/apache/jackrabbit/oak/plugins/index/search/util/QueryUtils.java:
##########
@@ -0,0 +1,55 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.jackrabbit.oak.plugins.index.search.util;
+
+public class QueryUtils {
+
+    public static final char WILDCARD_STRING = '*';
+    public static final char WILDCARD_CHAR = '?';
+    public static final char WILDCARD_ESCAPE = '\\';
+
+    private static void replaceWildcard(StringBuilder sb, int position, char 
oldWildcard, char newWildcard) {

Review Comment:
   The algorithm in this class was taken verbatim from LucenePropertyIndex:
   
   
https://github.com/apache/jackrabbit-oak/blob/27a7a9ffa0e78e5b258626aef24066eb58efc559/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1161-L1177
   
   This PR only updates Elastic to handle escaped wildcards in the same way as 
Lucene is doing and it assumes that Lucene's behavior is correct. I have moved 
the algorithm to this common class to avoid code duplication between Elastic 
and Lucene. Otherwise, I have not changed anything in the algorithm itself.
   
   I don't see a reason to change the algorithm, unless we have a reason to 
believe that Lucene's behavior is incorrect. And if that is the case, probably 
it should be done as a separate issue.
   
   That's also the reason I did not add any unit tests or documentation trying 
to explain the algorithm, as I just assumed it was correct and treated it as a 
black box. I did not try to understand it.



-- 
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]

Reply via email to