[jira] [Comment Edited] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260950#comment-15260950
]
Vikas Saurabh edited comment on OAK-4313 at 4/27/16 9:14 PM:
-
Fixed in [r1741343|https://svn.apache.org/r1741343] on trunk. Would start
backport post 1.4.2.
[~tmueller], can you please review? I've fixed OAK-4317 ({{return false}}
instead of {{throw}} in SImilarImpl and NativeFunctionImpl).
was (Author: catholicon):
Fixed in [r1741343|https://svn.apache.org/r1741343] on trunk. Would start
backport post 1.4.2.
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-4313.
Resolution: Fixed
Fix Version/s: (was: 1.4.2)
1.5.2
Fixed in [r1741343|https://svn.apache.org/r1741343] on trunk. Would start
backport post 1.4.2.
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-4313:
---
Priority: Major (was: Blocker)
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.5.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4317) Similar and Native queries should return no results if no index can handle them
[ https://issues.apache.org/jira/browse/OAK-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-4317. Resolution: Fixed Fix Version/s: 1.5.2 Fixed in [r1741339|https://svn.apache.org/r1741339] on trunk. > Similar and Native queries should return no results if no index can handle > them > --- > > Key: OAK-4317 > URL: https://issues.apache.org/jira/browse/OAK-4317 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.6, 1.5.2 > > > OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should > do the same for SimilarImpl and NativeFunctionImpl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4317) Similar and Native queries should return no results if no index can handle them
[ https://issues.apache.org/jira/browse/OAK-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-4317: --- Summary: Similar and Native queries should return no results if no index can handle them (was: SimilarImpl queries should return no results if no index can handle them) > Similar and Native queries should return no results if no index can handle > them > --- > > Key: OAK-4317 > URL: https://issues.apache.org/jira/browse/OAK-4317 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.6 > > > OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should > do the same for SimilarImpl. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4317) Similar and Native queries should return no results if no index can handle them
[ https://issues.apache.org/jira/browse/OAK-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-4317: --- Description: OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should do the same for SimilarImpl and NativeFunctionImpl (was: OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should do the same for SimilarImpl.) > Similar and Native queries should return no results if no index can handle > them > --- > > Key: OAK-4317 > URL: https://issues.apache.org/jira/browse/OAK-4317 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.6 > > > OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should > do the same for SimilarImpl and NativeFunctionImpl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4268) Clarify API contract for SyncResult.getIdentity
[
https://issues.apache.org/jira/browse/OAK-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260834#comment-15260834
]
Tobias Bocanegra edited comment on OAK-4268 at 4/27/16 8:02 PM:
I think there was not much thought put into defining when the identity could be
null.
I would really change the annotation. since the exact case when the identity
can be null was never explained, it doesn't really change the contract if we
make it stricter (if it would be the other ways around, i.e. allowing null all
of a sudden, it would be worse, and I wouldn't change it).
was (Author: tripod):
I think there was not much though put into when the identity could be null. I
would change the annotation. since the exact case when the identity can be null
was never explained, doesn't change the contract if we make it stricter (if it
would be the other ways around, i.e. allowing null all of a sudden, it would be
worse, and I wouldn't change it).
> Clarify API contract for SyncResult.getIdentity
> ---
>
> Key: OAK-4268
> URL: https://issues.apache.org/jira/browse/OAK-4268
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: Tobias Bocanegra
>
> [~tripod], I would appreciate if you could add some clarifying javadoc to
> {{SyncResult.getIdentity}} stating what the nature of the identity is
> expected to be for various status and what it means if the identity is
> {{null}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4268) Clarify API contract for SyncResult.getIdentity
[
https://issues.apache.org/jira/browse/OAK-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260834#comment-15260834
]
Tobias Bocanegra commented on OAK-4268:
---
I think there was not much though put into when the identity could be null. I
would change the annotation. since the exact case when the identity can be null
was never explained, doesn't change the contract if we make it stricter (if it
would be the other ways around, i.e. allowing null all of a sudden, it would be
worse, and I wouldn't change it).
> Clarify API contract for SyncResult.getIdentity
> ---
>
> Key: OAK-4268
> URL: https://issues.apache.org/jira/browse/OAK-4268
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: Tobias Bocanegra
>
> [~tripod], I would appreciate if you could add some clarifying javadoc to
> {{SyncResult.getIdentity}} stating what the nature of the identity is
> expected to be for various status and what it means if the identity is
> {{null}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4315) DefaultSyncHandler shouldn't apply automatic membership on existing users.
[ https://issues.apache.org/jira/browse/OAK-4315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260701#comment-15260701 ] angela commented on OAK-4315: - [~baedke], not sure if that is really a bug. in particular any changes to the auto-membership would no longer be reflected for existing synced-users. what makes you think that this is a bug? do you want to avoid extra-membership sync operations as long as the automembership hasn't changed? if that was the case, i would rather rephrase the report to something like "don't apply auto-membership if not changed"; this would allow to minimize the sync-effort while at the same time asserting that any modifications to the auto-membership configuration gets reflected upon resync. in general i think something like OAK-4087 would be a better approach on the long run. > DefaultSyncHandler shouldn't apply automatic membership on existing users. > -- > > Key: OAK-4315 > URL: https://issues.apache.org/jira/browse/OAK-4315 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Affects Versions: 1.0.30, 1.2.14, 1.5.1 >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > The DefaultSyncHandler applies automatic group membership on every user sync. > It should only be applied when a new user has been created by the sync > process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4301) Missing protection for system-maintained rep:externalId
[
https://issues.apache.org/jira/browse/OAK-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260666#comment-15260666
]
angela commented on OAK-4301:
-
In general defining a dedicated mixin type to identity external user/group
accounts and mark the required properties (rep:externalId and potentially
rep:lastSynced) mandatory + protected would look like the most natural and
desirable option to me.
However, initial work revealed that the nature of current user-sync API (in
particular {{SyncHandler}}) and the public (exported) default classes (in
particular {{DefaultSyncContext}}) essential makes an implementation of this
solution impossible; at least impossible without complete rewrite and
deprecation of the existing API.
Consequently, I would opt for an alternative approach that omit a dedicate node
type (i.e. making the protected nature also obvious and detectable with the JCR
API) in favor of an Oak-level protection. We may still reconsider heavy rewrite
of the sync-API on the long run but that's something that IMO would need
additional justification.
> Missing protection for system-maintained rep:externalId
>
>
> Key: OAK-4301
> URL: https://issues.apache.org/jira/browse/OAK-4301
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, security
>Reporter: angela
>Assignee: angela
>Priority: Critical
>
> while working on OAK-4101 i noticed that the current implementation doesn't
> provide any protection for the system maintained property {{rep:externalId}},
> which is intended to be an identifier for a given synchronized user/group
> within an external IDP.
> in other words:
> - the system doesn't assert the uniqueness of a given external-id
> - the external-id properties can be changed using regular JCR API
> up to now i didn't manage to exploit the missing protection with the current
> default implementation but i found that minor (legitimate) changes have the
> potential to turn this into a critical vulnerability.
> therefore I would strongly recommend to change the default implementation
> such that the rep:externalId really becomes system-maintained and prevent any
> unintentional or malicious modification outside of the scope of the
> sync-operations. furthermore uniqueness of this property should be asserted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4301) Missing protection for system-maintained rep:externalId
[
https://issues.apache.org/jira/browse/OAK-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned OAK-4301:
---
Assignee: angela
> Missing protection for system-maintained rep:externalId
>
>
> Key: OAK-4301
> URL: https://issues.apache.org/jira/browse/OAK-4301
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, security
>Reporter: angela
>Assignee: angela
>Priority: Critical
>
> while working on OAK-4101 i noticed that the current implementation doesn't
> provide any protection for the system maintained property {{rep:externalId}},
> which is intended to be an identifier for a given synchronized user/group
> within an external IDP.
> in other words:
> - the system doesn't assert the uniqueness of a given external-id
> - the external-id properties can be changed using regular JCR API
> up to now i didn't manage to exploit the missing protection with the current
> default implementation but i found that minor (legitimate) changes have the
> potential to turn this into a critical vulnerability.
> therefore I would strongly recommend to change the default implementation
> such that the rep:externalId really becomes system-maintained and prevent any
> unintentional or malicious modification outside of the scope of the
> sync-operations. furthermore uniqueness of this property should be asserted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4317) SimilarImpl queries should return no results if no index can handle them
[ https://issues.apache.org/jira/browse/OAK-4317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260636#comment-15260636 ] Vikas Saurabh commented on OAK-4317: Required by OAK-4313 due to test case expectation changes. > SimilarImpl queries should return no results if no index can handle them > > > Key: OAK-4317 > URL: https://issues.apache.org/jira/browse/OAK-4317 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.6 > > > OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should > do the same for SimilarImpl. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4247) Deprecate oak-segment
[
https://issues.apache.org/jira/browse/OAK-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4247:
---
Labels: technical_debt (was: )
> Deprecate oak-segment
> -
>
> Key: OAK-4247
> URL: https://issues.apache.org/jira/browse/OAK-4247
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next, segmentmk
>Reporter: Michael Dürig
>Priority: Blocker
> Labels: technical_debt
> Fix For: 1.6
>
>
> Before the next major release we need to deprecate {{oak-segment}} and make
> {{oak-segment-next}} the new default implementation:
> * Deprecate all classes in {{oak-segment}}
> * Update documentation to reflect this change
> * Update tooling to target {{oak-segment-next}} (See OAK-4246).
> * Update dependencies of upstream modules / projects from {{oak-segment}} to
> {{oak-segment-next}}.
> * Ensure {{oak-segment-next}} gets properly released (See OAK-4258).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4282) Make the number of retained gc generation configurable
[
https://issues.apache.org/jira/browse/OAK-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-4282.
Resolution: Fixed
Fixed at http://svn.apache.org/viewvc?rev=1741289&view=rev
> Make the number of retained gc generation configurable
> --
>
> Key: OAK-4282
> URL: https://issues.apache.org/jira/browse/OAK-4282
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: cleanup, gc
> Fix For: 1.6
>
>
> The number of retained gc generations ("brutal" cleanup strategy) is
> currently hard coded to 2. I think we need to make this configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260364#comment-15260364
]
Vikas Saurabh commented on OAK-4313:
Thanks for the patch [~tmueller]. I think TraversingCursor should not traverse
even for rep:similar case. That rep:similar throws and not return false like
others (spellcheck and suggest) should probably be corrected separately (may be
a new issue relating to this one and OAK-2548).
Tested a modified version (removed {{justOneRow}} and assert scanCount as 0)
which works for current oak-lucene and patched oak-core (also, requires
adjusting *sql2_native.txt similar to
[r1662456|https://svn.apache.org/r1662456]).
I'd like to commit the simplified patch as you suggested (opened OAK-4317 to
align SimilarImpl with SuggestImpl and SpellcheckImpl).
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.4.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4317) SimilarImpl queries should return no results if no index can handle them
Vikas Saurabh created OAK-4317: -- Summary: SimilarImpl queries should return no results if no index can handle them Key: OAK-4317 URL: https://issues.apache.org/jira/browse/OAK-4317 Project: Jackrabbit Oak Issue Type: Improvement Components: query Reporter: Vikas Saurabh Assignee: Vikas Saurabh Priority: Minor Fix For: 1.6 OAK-2548 fixed the same issue for SuggestImpl and SpellcheckImpl. We should do the same for SimilarImpl. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4284) Garbage left behind when compaction does not succeed
[ https://issues.apache.org/jira/browse/OAK-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-4284. Resolution: Fixed Fixed at http://svn.apache.org/viewvc?rev=1741276&view=rev > Garbage left behind when compaction does not succeed > > > Key: OAK-4284 > URL: https://issues.apache.org/jira/browse/OAK-4284 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-next >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: cleanup, compaction, gc > Fix For: 1.6 > > > As a result of the new cleanup approach introduced with OAK-3348 (brutal) a > compaction cycle that is not successful (either because of cancellation of > because of giving up waiting for the lock) leaves garbage behind, which is > only cleaned up 2 generations later. > We should look into ways to remove such garbage more pro-actively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-4284) Garbage left behind when compaction does not succeed
[ https://issues.apache.org/jira/browse/OAK-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig reassigned OAK-4284: -- Assignee: Michael Dürig > Garbage left behind when compaction does not succeed > > > Key: OAK-4284 > URL: https://issues.apache.org/jira/browse/OAK-4284 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-next >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: cleanup, compaction, gc > Fix For: 1.6 > > > As a result of the new cleanup approach introduced with OAK-3348 (brutal) a > compaction cycle that is not successful (either because of cancellation of > because of giving up waiting for the lock) leaves garbage behind, which is > only cleaned up 2 generations later. > We should look into ways to remove such garbage more pro-actively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260238#comment-15260238
]
Thomas Mueller commented on OAK-4313:
-
Sorry it took a bit longer than expected... here the patch. The idea is to use
the traversal index, but ensure that we don't traverse the whole repository.
Just one row at most. Scanning one row is needed for the rep:similar() case:
for this case, we still expect that an exception is thrown (OAK-2548 is just
for spellcheck and suggest, not for similarity search). Well if that's not
correct, then this patch could be simplified a bit. But I would keep the idea
to use traversal, but not traverse too much.
{noformat}
--- src/main/java/org/apache/jackrabbit/oak/spi/query/Cursors.java
(revision 1741187)
+++ src/main/java/org/apache/jackrabbit/oak/spi/query/Cursors.java
(working copy)
@@ -218,7 +218,9 @@
private final Deque> nodeIterators =
Queues.newArrayDeque();
-
+
+private boolean justOneRow;
+
private String parentPath;
private String currentPath;
@@ -241,6 +243,16 @@
NodeState parent = null;
NodeState node = rootState;
+if (filter.containsNativeConstraint()) {
+// OAK-4313: if no other index was found,
+// then we ensure that only one row is returned
+nodeIterators.add(Iterators.singletonIterator(
+new MemoryChildNodeEntry(currentPath, node)));
+parentPath = "";
+justOneRow = true;
+return;
+}
+
if (filter.isAlwaysFalse()) {
// nothing can match this filter, leave nodes empty
return;
@@ -326,6 +338,9 @@
continue;
}
currentPath = PathUtils.concat(parentPath, name);
+if (justOneRow) {
+return;
+}
PathRestriction r = filter.getPathRestriction();
if (r == PathRestriction.ALL_CHILDREN ||
Index: src/test/java/org/apache/jackrabbit/oak/query/NativeQueryTest.java
===
--- src/test/java/org/apache/jackrabbit/oak/query/NativeQueryTest.java
(revision 0)
+++ src/test/java/org/apache/jackrabbit/oak/query/NativeQueryTest.java
(working copy)
@@ -0,0 +1,92 @@
+/*
+ * 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.query;
+
+import static org.apache.jackrabbit.JcrConstants.JCR_SYSTEM;
+import static
org.apache.jackrabbit.oak.plugins.nodetype.NodeTypeConstants.JCR_NODE_TYPES;
+import static
org.apache.jackrabbit.oak.plugins.nodetype.write.InitialContent.INITIAL_CONTENT;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
+
+import java.text.ParseException;
+import java.util.Iterator;
+
+import org.apache.jackrabbit.oak.api.Result;
+import org.apache.jackrabbit.oak.api.ResultRow;
+import org.apache.jackrabbit.oak.api.Type;
+import org.apache.jackrabbit.oak.core.ImmutableRoot;
+import org.apache.jackrabbit.oak.namepath.NamePathMapper;
+import org.apache.jackrabbit.oak.spi.state.NodeState;
+import org.junit.Test;
+
+public class NativeQueryTest {
+
+private final NodeState types = INITIAL_CONTENT.getChildNode(JCR_SYSTEM)
+.getChildNode(JCR_NODE_TYPES);
+
+private final ImmutableRoot ROOT = new ImmutableRoot(INITIAL_CONTENT);
+private final QueryEngineImpl QUERY_ENGINE =
(QueryEngineImpl)ROOT.getQueryEngine();
+
+private final SQL2Parser p = new SQL2Parser(NamePathMapper.DEFAULT, types,
new QueryEngineSettings());
+
+@Test
+public void dontTraverseForSuggest() throws Exception {
+String sql = "select [rep:suggest()] from [nt:base] where
suggest('test')";
+assertDontTraverseFor(sql, "Suggest");
+}
+
+@Test
+public void dontTraverseForSpellcheck() throws Exception {
+String sql
[jira] [Updated] (OAK-3812) Disable compaction gain estimation if compaction is paused
[ https://issues.apache.org/jira/browse/OAK-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3812: -- Labels: candidate_oak_1_0 candidate_oak_1_2 compaction gc (was: candidate_oak_1_2 compaction gc) > Disable compaction gain estimation if compaction is paused > -- > > Key: OAK-3812 > URL: https://issues.apache.org/jira/browse/OAK-3812 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: candidate_oak_1_0, candidate_oak_1_2, compaction, gc > Fix For: 1.4, 1.3.14 > > > I think we should disable compaction estimation when compaction is paused. > Estimation interferes with the caches, wastes CPU and IO cycles and is not > essential for Oak's operation when compaction is disabled. The only reason it > was unconditionally enabled initially is to gather the respective information > in production. I think this has turned out to be not too useful so it is safe > to disable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3812) Disable compaction gain estimation if compaction is paused
[ https://issues.apache.org/jira/browse/OAK-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3812: -- Labels: candidate_oak_1_2 compaction gc (was: compaction gc) > Disable compaction gain estimation if compaction is paused > -- > > Key: OAK-3812 > URL: https://issues.apache.org/jira/browse/OAK-3812 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: candidate_oak_1_2, compaction, gc > Fix For: 1.4, 1.3.14 > > > I think we should disable compaction estimation when compaction is paused. > Estimation interferes with the caches, wastes CPU and IO cycles and is not > essential for Oak's operation when compaction is disabled. The only reason it > was unconditionally enabled initially is to gather the respective information > in production. I think this has turned out to be not too useful so it is safe > to disable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4316) The Jcr builder should accept a fully initialized Oak instance
[
https://issues.apache.org/jira/browse/OAK-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-4316.
-
Resolution: Fixed
Fix Version/s: 1.5.2
Fixed in r1741247.
> The Jcr builder should accept a fully initialized Oak instance
> --
>
> Key: OAK-4316
> URL: https://issues.apache.org/jira/browse/OAK-4316
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.6, 1.5.2
>
>
> {{Jcr}} initialises every instance of {{Oak}} currently passed to it. This
> prevents the usage of {{Jcr}} as a facade for the rest of the {{oak-jcr}}
> bundle. {{Jcr}} should provide a way to accept an instance of {{Oak}} without
> attaching to it the full set of {{Editor}}, {{CommitHook}}, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4316) The Jcr builder should accept a fully initialized Oak instance
Francesco Mari created OAK-4316:
---
Summary: The Jcr builder should accept a fully initialized Oak
instance
Key: OAK-4316
URL: https://issues.apache.org/jira/browse/OAK-4316
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Reporter: Francesco Mari
Assignee: Francesco Mari
Fix For: 1.6
{{Jcr}} initialises every instance of {{Oak}} currently passed to it. This
prevents the usage of {{Jcr}} as a facade for the rest of the {{oak-jcr}}
bundle. {{Jcr}} should provide a way to accept an instance of {{Oak}} without
attaching to it the full set of {{Editor}}, {{CommitHook}}, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4315) DefaultSyncHandler shouldn't apply automatic membership on existing users.
Manfred Baedke created OAK-4315: --- Summary: DefaultSyncHandler shouldn't apply automatic membership on existing users. Key: OAK-4315 URL: https://issues.apache.org/jira/browse/OAK-4315 Project: Jackrabbit Oak Issue Type: Bug Components: auth-external Affects Versions: 1.5.1, 1.2.14, 1.0.30 Reporter: Manfred Baedke Assignee: Manfred Baedke Priority: Minor The DefaultSyncHandler applies automatic group membership on every user sync. It should only be applied when a new user has been created by the sync process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4278) Fix backup and restore
[
https://issues.apache.org/jira/browse/OAK-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4278:
---
Fix Version/s: 1.5.2
> Fix backup and restore
> --
>
> Key: OAK-4278
> URL: https://issues.apache.org/jira/browse/OAK-4278
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Alex Parvulescu
> Labels: backup, restore, technical_debt
> Fix For: 1.6, 1.5.2
>
>
> {{FileStoreBackup}} and {{FileStoreRestore}} are currently broken as a side
> effect of the fix from OAK-3348. ({{FileStoreBackupTest}} is currently being
> skipped).
> In {{oak-segment}} backup and restore functionality relied on the
> {{Compactor}} class. The latter is gone in {{oak-segment-next}} as it is not
> needed for online compaction any more.
> Instead of sharing functionality from compaction directly, I think backup and
> restore should come up with its own implementation that could be individually
> tweaked for its task. If there is commonalities with offline compaction those
> can still be shared thorough a common base class. See OAK-4279
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4246) Update segment tooling to choose target store
[
https://issues.apache.org/jira/browse/OAK-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4246:
---
Priority: Blocker (was: Major)
> Update segment tooling to choose target store
> -
>
> Key: OAK-4246
> URL: https://issues.apache.org/jira/browse/OAK-4246
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Blocker
> Labels: tooling
> Fix For: 1.6, 1.5.2
>
>
> We need to add command line options segment specific tooling so users could
> chose between {{oak-segment}} and {{oak-segment-next}}. {{oak-segment}}
> should be the default until deprecated, where {{oak-segment-next}} should be
> made the default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4279) Rework offline compaction
[
https://issues.apache.org/jira/browse/OAK-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4279:
---
Fix Version/s: 1.5.2
> Rework offline compaction
> -
>
> Key: OAK-4279
> URL: https://issues.apache.org/jira/browse/OAK-4279
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Alex Parvulescu
> Labels: compaction, gc
> Fix For: 1.6, 1.5.2
>
>
> The fix for OAK-3348 broke some of the previous functionality of offline
> compaction:
> * No more progress logging
> * Compaction is not interruptible any more (in the sense of OAK-3290)
> * Offline compaction could remove the ids of the segment node states to
> squeeze out some extra space. Those are only needed for later generations
> generated via online compaction.
> We should probably implement offline compaction again through a dedicated
> {{Compactor}} class as it was done in {{oak-segment}} instead of relying on
> the de-duplication cache (aka online compaction).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4279) Rework offline compaction
[
https://issues.apache.org/jira/browse/OAK-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4279:
---
Priority: Blocker (was: Major)
> Rework offline compaction
> -
>
> Key: OAK-4279
> URL: https://issues.apache.org/jira/browse/OAK-4279
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: compaction, gc
> Fix For: 1.6, 1.5.2
>
>
> The fix for OAK-3348 broke some of the previous functionality of offline
> compaction:
> * No more progress logging
> * Compaction is not interruptible any more (in the sense of OAK-3290)
> * Offline compaction could remove the ids of the segment node states to
> squeeze out some extra space. Those are only needed for later generations
> generated via online compaction.
> We should probably implement offline compaction again through a dedicated
> {{Compactor}} class as it was done in {{oak-segment}} instead of relying on
> the de-duplication cache (aka online compaction).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4278) Fix backup and restore
[
https://issues.apache.org/jira/browse/OAK-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4278:
---
Priority: Blocker (was: Major)
> Fix backup and restore
> --
>
> Key: OAK-4278
> URL: https://issues.apache.org/jira/browse/OAK-4278
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Alex Parvulescu
>Priority: Blocker
> Labels: backup, restore, technical_debt
> Fix For: 1.6, 1.5.2
>
>
> {{FileStoreBackup}} and {{FileStoreRestore}} are currently broken as a side
> effect of the fix from OAK-3348. ({{FileStoreBackupTest}} is currently being
> skipped).
> In {{oak-segment}} backup and restore functionality relied on the
> {{Compactor}} class. The latter is gone in {{oak-segment-next}} as it is not
> needed for online compaction any more.
> Instead of sharing functionality from compaction directly, I think backup and
> restore should come up with its own implementation that could be individually
> tweaked for its task. If there is commonalities with offline compaction those
> can still be shared thorough a common base class. See OAK-4279
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4246) Update segment tooling to choose target store
[
https://issues.apache.org/jira/browse/OAK-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4246:
---
Fix Version/s: 1.5.2
> Update segment tooling to choose target store
> -
>
> Key: OAK-4246
> URL: https://issues.apache.org/jira/browse/OAK-4246
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Francesco Mari
> Labels: tooling
> Fix For: 1.6, 1.5.2
>
>
> We need to add command line options segment specific tooling so users could
> chose between {{oak-segment}} and {{oak-segment-next}}. {{oak-segment}}
> should be the default until deprecated, where {{oak-segment-next}} should be
> made the default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4285) Align cleanup of segment id tables with the new cleanup strategy
[
https://issues.apache.org/jira/browse/OAK-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4285:
---
Attachment: OAK_4285.patch
While working on OAK-4312 I tentatively came up with a patch for this issue:
[^OAK_4285.patch].
However after further considerations I'm note convinced that this is the right
thing to do. Maybe we should do nothing here. I.e. no clean up of the segment
id tables at all. After all, these tables track segment ids that are references
from somewhere within the JVM. Whether or not the underlying segment exists or
has been reclaimed is a different concern. Maybe we should just add an explicit
not to that respect to {{SegmentTracker#getReferencedSegmentIds}}.
[~alex.parvulescu], [~frm], WDYT?
> Align cleanup of segment id tables with the new cleanup strategy
> -
>
> Key: OAK-4285
> URL: https://issues.apache.org/jira/browse/OAK-4285
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Alex Parvulescu
> Labels: cleanup, gc
> Fix For: 1.6
>
> Attachments: OAK_4285.patch
>
>
> We need to align cleanup of the segment id tables with the new "brutal"
> strategy introduced with OAK-3348. That is, we need to remove those segment
> id's from the segment id tables whose segment have actually been gc'ed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4265) XPath: support limited form of "union"
[
https://issues.apache.org/jira/browse/OAK-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259930#comment-15259930
]
Thomas Mueller commented on OAK-4265:
-
http://svn.apache.org/r1741199 (work in progress)
> XPath: support limited form of "union"
> --
>
> Key: OAK-4265
> URL: https://issues.apache.org/jira/browse/OAK-4265
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.6
>
>
> Currently, SQL-2 supports multiple paths restrictions combined with "or", and
> it supports "union". XPath doesn't support either. It would be good if this
> is supported, specially the "multiple paths" part.
> I think it makes sense to convert this to a SQL-2 "union" in all cases, even
> if it's just multiple paths.
> It doesn't need to be a "generic" solution, so that "|" doesn't need to be
> supported at every place (for example in the condition, or in the "order
> by"). But it would be nice if multiple independent queries, with one order
> by, could be supported.
> Implementation note: what makes this a bit complicated is support for "order
> by".
> For example:
> {noformat}
> /jcr:root/(content|lib)/element(*, nt:base) order by @title
> select [jcr:path], [jcr:score], *
> from [nt:base] as a
> where ischildnode(a, '/content')
> /* xpath: /jcr:root/content/element(*, nt:base) order by @title */
> union select [jcr:path], [jcr:score], *
> from [nt:base] as a
> where ischildnode(a, '/lib')
> /* xpath: /jcr:root/lib/element(*, nt:base) order by @title */
> order by [title]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4312) Fix test failures in SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-4312.
Resolution: Fixed
> Fix test failures in SegmentDataStoreBlobGCIT
> -
>
> Key: OAK-4312
> URL: https://issues.apache.org/jira/browse/OAK-4312
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: cleanup, gc
> Fix For: 1.6
>
>
> {{SegmentDataStoreBlobGCIT#gcWithInlined}}, {{gc}},
> {{gcLongRunningBlobCollection}} and {{consistencyCheckWithGc}} fail since the
> removal of the old cleanup strategy in OAK-4276.
> The test setup needs to be adapted to the brutal strategy: i.e. {{setup()}}
> needs to simulate so many compaction cycles until a subsequent cleanup
> actually remove the segments in question.
> This is not sufficient though as then
> {{SegmentTracker#collectBlobReferences}} causes a SNFE for those segment ids
> actually removed but still in the segment id tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4312) Fix test failures in SegmentDataStoreBlobGCIT
[
https://issues.apache.org/jira/browse/OAK-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259919#comment-15259919
]
Michael Dürig commented on OAK-4312:
Fixed at http://svn.apache.org/viewvc?rev=1741194&view=rev.
Relying on the segment id tables for collecting blob references does not work
reliably any more with the brutal cleanup strategy (OAK-3348): the tables might
still contain ids from segments that have been reclaimed. Aligning them with
the segments on disk is topic of OAK-4285 and I'll follow up there with my
concerns there.
I reimplemented blob reference collection: instead of following the reference
graph, the reference are now retrieved from the tar files (and the segments
therein). This 1) decouples blob reference collection from the segment id
tables and 2) can be seen as preparatory step towards OAK-4201. I left a FIXME
tag to this respect in the code.
FYI [~amitjain], [~chetanm]
> Fix test failures in SegmentDataStoreBlobGCIT
> -
>
> Key: OAK-4312
> URL: https://issues.apache.org/jira/browse/OAK-4312
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-next
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: cleanup, gc
> Fix For: 1.6
>
>
> {{SegmentDataStoreBlobGCIT#gcWithInlined}}, {{gc}},
> {{gcLongRunningBlobCollection}} and {{consistencyCheckWithGc}} fail since the
> removal of the old cleanup strategy in OAK-4276.
> The test setup needs to be adapted to the brutal strategy: i.e. {{setup()}}
> needs to simulate so many compaction cycles until a subsequent cleanup
> actually remove the segments in question.
> This is not sufficient though as then
> {{SegmentTracker#collectBlobReferences}} causes a SNFE for those segment ids
> actually removed but still in the segment id tables.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-4314) BlobReferenceRetriever#collectReferences should allow exceptions
[
https://issues.apache.org/jira/browse/OAK-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain reassigned OAK-4314:
--
Assignee: Amit Jain
> BlobReferenceRetriever#collectReferences should allow exceptions
>
>
> Key: OAK-4314
> URL: https://issues.apache.org/jira/browse/OAK-4314
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
>Assignee: Amit Jain
> Labels: datastore, gc, resilience
> Fix For: 1.6
>
>
> {{BlobReferenceRetriever#collectReferences}} currently does not allow
> implementations to throw an exception. In case anything goes wrong during
> reference collection, implementations should be able to indicate this through
> an exception so the DSGC can safely abort.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4314) BlobReferenceRetriever#collectReferences should allow exceptions
[
https://issues.apache.org/jira/browse/OAK-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-4314:
---
Labels: datastore gc resilience (was: datastore gc)
> BlobReferenceRetriever#collectReferences should allow exceptions
>
>
> Key: OAK-4314
> URL: https://issues.apache.org/jira/browse/OAK-4314
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
> Labels: datastore, gc, resilience
> Fix For: 1.6
>
>
> {{BlobReferenceRetriever#collectReferences}} currently does not allow
> implementations to throw an exception. In case anything goes wrong during
> reference collection, implementations should be able to indicate this through
> an exception so the DSGC can safely abort.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259877#comment-15259877
]
Vikas Saurabh commented on OAK-4313:
Yes, you're right. What I want to do is avoid repository traversal. Skipping
TraversingIndex was the simplest approach I could think of (admittedly, I'm not
too sure of how to do "where 1=0" kind of condition).
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.4.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259876#comment-15259876
]
Vikas Saurabh commented on OAK-4313:
The issue got more relevant with OAK-3838 as before that a lucene index which
doesn't support suggestion also declared to 'support' suggestions (i.e. it
didn't say INIFINITY for cost) and hence avoided the traversal.
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.4.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4314) BlobReferenceRetriever#collectReferences should allow exceptions
Michael Dürig created OAK-4314:
--
Summary: BlobReferenceRetriever#collectReferences should allow
exceptions
Key: OAK-4314
URL: https://issues.apache.org/jira/browse/OAK-4314
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Michael Dürig
Fix For: 1.6
{{BlobReferenceRetriever#collectReferences}} currently does not allow
implementations to throw an exception. In case anything goes wrong during
reference collection, implementations should be able to indicate this through
an exception so the DSGC can safely abort.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-4313:
---
Priority: Blocker (was: Major)
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.4.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-4313:
---
Fix Version/s: 1.4.2
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.4.2
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4308) Align the UpgradeTest#upgradeFrom10 to oak-segment-next
[
https://issues.apache.org/jira/browse/OAK-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek resolved OAK-4308.
Resolution: Fixed
Fix Version/s: 1.5.2
> Align the UpgradeTest#upgradeFrom10 to oak-segment-next
> ---
>
> Key: OAK-4308
> URL: https://issues.apache.org/jira/browse/OAK-4308
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: jcr, segment-next
>Reporter: Tomek Rękawek
>Priority: Minor
> Labels: migration, upgrade
> Fix For: 1.6, 1.5.2
>
>
> Test case {{UpgradeTest#upgradeFrom10}} in the {{oak-jcr}} module unpacks an
> archived TarMK repository in the Oak 1.0 format and tries to run the current
> oak-segment on top on that. It also validates whether all the data are in
> place.
> This works, because the oak-segment code automatically detects the old
> repository format and upgrades it in-place, without any user action.
> However, after changing this test to use the oak-segment-next it'll break,
> because the upgrade path for the new repository code is more complex - it
> requires invoking the oak-upgrade manually, to sidegrade the data (as in
> OAK-4260).
> We should move this test to the oak-upgrade module and modify it a bit, so
> the data are sidegraded before the repository is validated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4308) Align the UpgradeTest#upgradeFrom10 to oak-segment-next
[
https://issues.apache.org/jira/browse/OAK-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259789#comment-15259789
]
Tomek Rękawek commented on OAK-4308:
Fixed for trunk in [r1741163|http://svn.apache.org/r1741163].
> Align the UpgradeTest#upgradeFrom10 to oak-segment-next
> ---
>
> Key: OAK-4308
> URL: https://issues.apache.org/jira/browse/OAK-4308
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: jcr, segment-next
>Reporter: Tomek Rękawek
>Priority: Minor
> Labels: migration, upgrade
> Fix For: 1.6
>
>
> Test case {{UpgradeTest#upgradeFrom10}} in the {{oak-jcr}} module unpacks an
> archived TarMK repository in the Oak 1.0 format and tries to run the current
> oak-segment on top on that. It also validates whether all the data are in
> place.
> This works, because the oak-segment code automatically detects the old
> repository format and upgrades it in-place, without any user action.
> However, after changing this test to use the oak-segment-next it'll break,
> because the upgrade path for the new repository code is more complex - it
> requires invoking the oak-upgrade manually, to sidegrade the data (as in
> OAK-4260).
> We should move this test to the oak-upgrade module and modify it a bit, so
> the data are sidegraded before the repository is validated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4313) QueryImpl should avoid traversal with queries containing native constraints
[
https://issues.apache.org/jira/browse/OAK-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259785#comment-15259785
]
Thomas Mueller commented on OAK-4313:
-
Sorry I don't understand the logic behind the fix and the test. The assertion
in the test is a bit strange:
{noformat}
assertTrue(queryType + " query without supporting index mustn't traverse",
!(index !=null && index instanceof TraversingIndex));
{noformat}
So the test passes if _any_ other index is used (a property index for example).
Why is the traversing index so bad, and any other index is better? Maybe the
cost of traversing is lower than the cost of using a property index. A property
index doesn't support spellcheck and suggest, the same as the traversal index.
Maybe you want to ensure the following:
* (a) if an index supports native queries, then use that one (if multiple such
indexes are available, use the one with the lowest cost).
* (b) if no such index is available that supports native queries, then return
no rows in all cases.
If this is correct, then I suggest for the case (b) we use the traverse index,
but add a new condition that is always wrong (kind of like adding "where 1=0").
I can come up with a patch for the query engine.
> QueryImpl should avoid traversal with queries containing native constraints
> ---
>
> Key: OAK-4313
> URL: https://issues.apache.org/jira/browse/OAK-4313
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6
>
> Attachments: OAK-4313.patch
>
>
> If no index supports suggestion (or spellcheck or similar) query, then a
> query like
> {noformat}
> SELECT * from [nt:base] where SUGGEST('test')
> {noformat}
> shouldn't get traversing index
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4265) XPath: support limited form of "union"
[
https://issues.apache.org/jira/browse/OAK-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259700#comment-15259700
]
Thomas Mueller commented on OAK-4265:
-
> Can we leverage the optimisation hook we provided with OAK-1617 for
> generating alternatives that will be considered then by costs?
We could, but I don't think this is very important or urgent. The alternatives
would be to either use a union, or just one query with a limited (or no) path
restriction actually used by the index.
> XPath: support limited form of "union"
> --
>
> Key: OAK-4265
> URL: https://issues.apache.org/jira/browse/OAK-4265
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.6
>
>
> Currently, SQL-2 supports multiple paths restrictions combined with "or", and
> it supports "union". XPath doesn't support either. It would be good if this
> is supported, specially the "multiple paths" part.
> I think it makes sense to convert this to a SQL-2 "union" in all cases, even
> if it's just multiple paths.
> It doesn't need to be a "generic" solution, so that "|" doesn't need to be
> supported at every place (for example in the condition, or in the "order
> by"). But it would be nice if multiple independent queries, with one order
> by, could be supported.
> Implementation note: what makes this a bit complicated is support for "order
> by".
> For example:
> {noformat}
> /jcr:root/(content|lib)/element(*, nt:base) order by @title
> select [jcr:path], [jcr:score], *
> from [nt:base] as a
> where ischildnode(a, '/content')
> /* xpath: /jcr:root/content/element(*, nt:base) order by @title */
> union select [jcr:path], [jcr:score], *
> from [nt:base] as a
> where ischildnode(a, '/lib')
> /* xpath: /jcr:root/lib/element(*, nt:base) order by @title */
> order by [title]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
