[jira] [Resolved] (OAK-2196) Implement sorting based on Lucene sorting
[ https://issues.apache.org/jira/browse/OAK-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2196. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 Merged to 1.0 branch in * http://svn.apache.org/r1635674 * http://svn.apache.org/r1635704 > Implement sorting based on Lucene sorting > - > > Key: OAK-2196 > URL: https://issues.apache.org/jira/browse/OAK-2196 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.0.8, 1.1.2 > > > Make use of Lucene sorting support to implement sorting for JCR queries -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2239) Do not wrap LucenePropertyIndex with AggregateIndex
[ https://issues.apache.org/jira/browse/OAK-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2239. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 Merged to 1.0 branch in http://svn.apache.org/r1635702 > Do not wrap LucenePropertyIndex with AggregateIndex > --- > > Key: OAK-2239 > URL: https://issues.apache.org/jira/browse/OAK-2239 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.0.8, 1.1.2 > > > To avoid confusion with LuceneIndex usage it would be better to > # Not wrap the LucenePropertyIndex with AggregateIndex as thats only required > for full text indexes > # Use a different index name > See http://markmail.org/thread/ip67kfew6eq5dp4u -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2236) Support queries with only order by specified
[
https://issues.apache.org/jira/browse/OAK-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2236.
--
Resolution: Fixed
Fix Version/s: (was: 1.2)
1.1.2
Merged the fix to 1.0 branch with http://svn.apache.org/r1635698
> Support queries with only order by specified
>
>
> Key: OAK-2236
> URL: https://issues.apache.org/jira/browse/OAK-2236
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.0.8, 1.1.2
>
>
> Allow use of Lucene property index for cases where query specifies an order
> by clause and does not specify the where clause i.e. for an index definition
> like below
> {code}
> {
> "test": {
> "orderedProps": [
> "foo"
> ],
> "properties": {
> "foo": {
> "type": "Long"
> }
> }
> }
> }
> {code}
> And query like
> {noformat}
> select [jcr:path] from [nt:base] order by [foo]
> {noformat}
> Lucene should be use to return an order result
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2235) Lucene index not created if no node is indexed
[
https://issues.apache.org/jira/browse/OAK-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2235.
--
Resolution: Fixed
Fix Version/s: (was: 1.2)
1.1.2
Merged to 1.0 branch in http://svn.apache.org/r1635696
> Lucene index not created if no node is indexed
> --
>
> Key: OAK-2235
> URL: https://issues.apache.org/jira/browse/OAK-2235
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.0.8, 1.1.2
>
>
> If a Lucene property index is defined for a property which is not present in
> any of the nodes then {{LuceneIndexWriter}} would create any lucene index for
> that.
> For eg if we have an index of {{foo}} and none of the node has property
> {{foo}} set in that case {{LuceneIndexWriter}} would not create an
> {{IndexWriter}} and hence no directory would be created. Later when system
> performs a query like {{select jcr:path from nt:base where foo = 'bar'}} then
> {{LucenePropertyIndex}} would not participate in the query as no Lucene index
> would be found and system would revert to traversal.
> As a fix Lucene index should still be created even if it does not contain any
> document
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2234) Support property existence query
[
https://issues.apache.org/jira/browse/OAK-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191492#comment-14191492
]
Chetan Mehrotra commented on OAK-2234:
--
Merged the current impl to 1.0 branch in http://svn.apache.org/r1635693.
However would keep the issue open to implement the newer approach
> Support property existence query
>
>
> Key: OAK-2234
> URL: https://issues.apache.org/jira/browse/OAK-2234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.0.9, 1.2
>
>
> Add support for property existence query like
> {noformat}
> select [jcr:path] from [nt:base] where propa is not null
> {noformat}
> Opposite of this cannot be be supported i.e. {{propa is null}} though!
> With OAK-1208 query creation logic explicitly ignores such queries but with
> recent Lucene changes it appears to be possible LUCENE-995
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2234) Support property existence query
[
https://issues.apache.org/jira/browse/OAK-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191483#comment-14191483
]
Chetan Mehrotra commented on OAK-2234:
--
bq. fyi: http://markmail.org/message/kheqlwqrurquc36y
Thanks [~teofili]. The fact that result is not accurate in range queries means
we would need to go the route of indexing the propertyNames or use the filter.
> Support property existence query
>
>
> Key: OAK-2234
> URL: https://issues.apache.org/jira/browse/OAK-2234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.0.9, 1.2
>
>
> Add support for property existence query like
> {noformat}
> select [jcr:path] from [nt:base] where propa is not null
> {noformat}
> Opposite of this cannot be be supported i.e. {{propa is null}} though!
> With OAK-1208 query creation logic explicitly ignores such queries but with
> recent Lucene changes it appears to be possible LUCENE-995
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2234) Support property existence query
[
https://issues.apache.org/jira/browse/OAK-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2234:
-
Fix Version/s: (was: 1.0.8)
1.0.9
> Support property existence query
>
>
> Key: OAK-2234
> URL: https://issues.apache.org/jira/browse/OAK-2234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.0.9, 1.2
>
>
> Add support for property existence query like
> {noformat}
> select [jcr:path] from [nt:base] where propa is not null
> {noformat}
> Opposite of this cannot be be supported i.e. {{propa is null}} though!
> With OAK-1208 query creation logic explicitly ignores such queries but with
> recent Lucene changes it appears to be possible LUCENE-995
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2234) Support property existence query
[
https://issues.apache.org/jira/browse/OAK-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2234:
-
Issue Type: Improvement (was: Sub-task)
Parent: (was: OAK-2005)
> Support property existence query
>
>
> Key: OAK-2234
> URL: https://issues.apache.org/jira/browse/OAK-2234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.0.8, 1.2
>
>
> Add support for property existence query like
> {noformat}
> select [jcr:path] from [nt:base] where propa is not null
> {noformat}
> Opposite of this cannot be be supported i.e. {{propa is null}} though!
> With OAK-1208 query creation logic explicitly ignores such queries but with
> recent Lucene changes it appears to be possible LUCENE-995
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2198) Add support for declaringNodeTypes to only index node with specific types
[ https://issues.apache.org/jira/browse/OAK-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2198. -- Resolution: Fixed Merged to 1.0 in * http://svn.apache.org/r1635689 * http://svn.apache.org/r1635681 > Add support for declaringNodeTypes to only index node with specific types > - > > Key: OAK-2198 > URL: https://issues.apache.org/jira/browse/OAK-2198 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Amit Jain > Fix For: 1.0.8, 1.1.2 > > Attachments: OAK-2198.patch > > > Add support for declaringNodeTypes to only index node with specific types. > Also have a look at OAK-388 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-1724) Enable copying of Lucene index to local file system for read queries
[ https://issues.apache.org/jira/browse/OAK-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-1724. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 Merged to 1.0 branch in * http://svn.apache.org/r1635686 * http://svn.apache.org/r1635688 > Enable copying of Lucene index to local file system for read queries > > > Key: OAK-1724 > URL: https://issues.apache.org/jira/browse/OAK-1724 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.0.8, 1.1.2 > > Attachments: OAK-1724-copyonread-directory-2.patch, > OAK-1724-copyonread-directory.patch > > > Currently the Lucene index is stored in NodeStore and is accessed via > OakDirectory which is an implementation of [Lucene > Directory|https://lucene.apache.org/core/4_0_0/core/org/apache/lucene/store/Directory.html]. > This would work fine for SegmentStore but does not work very well when > BlobStore is used as with DocumentNodeStore > For such scenarios it should be possible to copy the Lucene index to local > file system and then read queries are performed using that. IndexWriter would > continue to use the OakDirectory to store the updated index content in > NodeStore. > As Lucene does not modify any index file once created (ther are either > deleted or new one created), it should be possible to incrementally update > the index by copying newly created segment files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2200) Tune cost calculation for lucene property index
[
https://issues.apache.org/jira/browse/OAK-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2200.
--
Resolution: Fixed
Fix Version/s: (was: 1.2)
1.1.2
Merged the fix to 1.0 branch with http://svn.apache.org/r1635687
> Tune cost calculation for lucene property index
> ---
>
> Key: OAK-2200
> URL: https://issues.apache.org/jira/browse/OAK-2200
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Amit Jain
>Assignee: Amit Jain
> Fix For: 1.0.8, 1.1.2
>
> Attachments: OAK-2200.patch
>
>
> Though lucene provides an accurate count with {{IndexReader#numDocs}}, we may
> need to apply heuristics to constrain the value so that it is properly
> selected for indexed properties Vs other inappropriate indexes e.g wrt
> nodeType index.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2125) Integrate Lucene logging with Slf4j
[ https://issues.apache.org/jira/browse/OAK-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2125. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 Integrated to 1.0 branch with http://svn.apache.org/r1635685 > Integrate Lucene logging with Slf4j > --- > > Key: OAK-2125 > URL: https://issues.apache.org/jira/browse/OAK-2125 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.0.8, 1.1.2 > > > Lucene creates debug logging which are routed via > [InfoStream|http://lucene.apache.org/core/4_0_0/core/org/apache/lucene/util/InfoStream.html]. > Currently there is no way to enable that in Oak. We should provide a way to > route the logs via slf4j -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2210) Add support for customizing the codec
[ https://issues.apache.org/jira/browse/OAK-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2210. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 Merged to 1.0 branch with http://svn.apache.org/r1635683 > Add support for customizing the codec > - > > Key: OAK-2210 > URL: https://issues.apache.org/jira/browse/OAK-2210 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.0.8, 1.1.2 > > > Currently we use OakCodec which disables compression. For property index > where we do not store the full text it might be better to allow changing the > code. > Further for property index by default no codec should be set and let Lucene > use its default codec for that version -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2211) Use Lucene index on non root node
[ https://issues.apache.org/jira/browse/OAK-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2211. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 Merged to 1.0 branch with http://svn.apache.org/r1635682 > Use Lucene index on non root node > -- > > Key: OAK-2211 > URL: https://issues.apache.org/jira/browse/OAK-2211 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.0.8, 1.1.2 > > > Use Lucene index on non root node. See also OAK-1980 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2201) Make blobSize in OakDirectory configurable
[ https://issues.apache.org/jira/browse/OAK-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2201. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 Merged to 1.0 branch with http://svn.apache.org/r1635679 > Make blobSize in OakDirectory configurable > -- > > Key: OAK-2201 > URL: https://issues.apache.org/jira/browse/OAK-2201 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.0.8, 1.1.2 > > Attachments: OAK-2201.patch > > > Currently OakDirectory in Lucene splits the index file in size of 32kb. It > would be better if this this is made configurable. > # Possibility to set it to higher value like 1MB - Original size was kept > small to allow them to be made part of Segment data itself and make use of > MMap IO. However when working with DocumentNodeStore it does not provide much > benifit. > # As the value is power of 2 it causes wasted space when blobs are stored in > MongoDocumentStore (OAK-2105) > Any change should be backward compatibile -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2205) Allow native query to be run against specifc property index
[
https://issues.apache.org/jira/browse/OAK-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191426#comment-14191426
]
Chetan Mehrotra commented on OAK-2205:
--
Merged the change in trunk to branch 1.0 with http://svn.apache.org/r1635677
The feature would not work with LucenePropertyIndex due to OAK-2241
> Allow native query to be run against specifc property index
> ---
>
> Key: OAK-2205
> URL: https://issues.apache.org/jira/browse/OAK-2205
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.0.8, 1.2
>
>
> With support for multiple Lucene indexes its not possible to allow a native
> query to pickup specific Lucene index
> bq. select [jcr:path] from [nt:base] where native('lucene', 'name:(Hello OR
> World)')
> To support running this query against a specific Lucene property index 'foo'
> we can encode the index name in function name
> bq. select [jcr:path] from [nt:base] where native('foo', 'name:(Hello OR
> World)')
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2204) Support for changing the precision used for storing the date values
[ https://issues.apache.org/jira/browse/OAK-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-2204: - Issue Type: Improvement (was: Sub-task) Parent: (was: OAK-2005) > Support for changing the precision used for storing the date values > --- > > Key: OAK-2204 > URL: https://issues.apache.org/jira/browse/OAK-2204 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.2 > > > Date values in JCR are stored as milliseconds. In many case it would be ok to > save the value with lower precision thus reducing the storage cost > Before exposing this option we need to benchmark the space gain made by > loosing the precision > Also see OAK-2028 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1778) Ordered index: explain plan not implemented
[ https://issues.apache.org/jira/browse/OAK-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191300#comment-14191300 ] Chetan Mehrotra commented on OAK-1778: -- Copied the changes done in QueryIndex interface to branch 1.0 with http://svn.apache.org/r1635664 > Ordered index: explain plan not implemented > --- > > Key: OAK-1778 > URL: https://issues.apache.org/jira/browse/OAK-1778 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.1.0 > > > The "plan" feature of the ordered index is not implemented. That means, > "explain select" will not return the correct plan when using the ordered > index. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2119) AggregateIndex should support AdvanceQueryIndex
[
https://issues.apache.org/jira/browse/OAK-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2119.
--
Resolution: Fixed
Fix Version/s: (was: 1.2)
1.1.2
Merged to 1.0 branch with
* http://svn.apache.org/r1635659
* http://svn.apache.org/r1635663
> AggregateIndex should support AdvanceQueryIndex
> ---
>
> Key: OAK-2119
> URL: https://issues.apache.org/jira/browse/OAK-2119
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.1.2
>
> Attachments: OAK-2119.patch
>
>
> Currently AggregateIndex is based on FulltextQueryIndex and thus support
> default QueryIndex. With OAK-2005 LuceneIndex would be implementing the
> {{AdvanceQueryIndex}}. To support that {{AggregateIndex}} should also support
> {{AdvanceQueryIndex}} based {{FulltextQueryIndex}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2226) Aggregate Lucene no results for multiple jcr:contains
[
https://issues.apache.org/jira/browse/OAK-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2226:
-
Fix Version/s: (was: 1.2)
> Aggregate Lucene no results for multiple jcr:contains
> -
>
> Key: OAK-2226
> URL: https://issues.apache.org/jira/browse/OAK-2226
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-lucene, query
>Affects Versions: 1.1.1
>Reporter: Davide Giannella
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.1.2
>
> Attachments: OAK-2226-AggregateIndex-trunk.patch,
> OAK-2226.test-r2.patch, OAK-2226.test-r3.patch, OAK-2226.test.patch
>
>
> When running queries like
> {code}
> /jcr:root/content//element(*, nt:unstructured)[
> (jcr:contains(., 'mountain'))
> and (jcr:contains(jcr:content/metadata/@format, 'image'))]
> {code}
> Lucene does not return any node
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2226) Aggregate Lucene no results for multiple jcr:contains
[
https://issues.apache.org/jira/browse/OAK-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191284#comment-14191284
]
Chetan Mehrotra commented on OAK-2226:
--
Merged the fix to 1.0 in http://svn.apache.org/r1635662
> Aggregate Lucene no results for multiple jcr:contains
> -
>
> Key: OAK-2226
> URL: https://issues.apache.org/jira/browse/OAK-2226
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-lucene, query
>Affects Versions: 1.1.1
>Reporter: Davide Giannella
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.2, 1.1.2
>
> Attachments: OAK-2226-AggregateIndex-trunk.patch,
> OAK-2226.test-r2.patch, OAK-2226.test-r3.patch, OAK-2226.test.patch
>
>
> When running queries like
> {code}
> /jcr:root/content//element(*, nt:unstructured)[
> (jcr:contains(., 'mountain'))
> and (jcr:contains(jcr:content/metadata/@format, 'image'))]
> {code}
> Lucene does not return any node
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2229) Provide a way for Index implementation to determine reindex mode
[ https://issues.apache.org/jira/browse/OAK-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2229. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 Merged to branch 1.0 with http://svn.apache.org/r1635661 > Provide a way for Index implementation to determine reindex mode > > > Key: OAK-2229 > URL: https://issues.apache.org/jira/browse/OAK-2229 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.0.8, 1.1.2 > > > In some cases where index content is managed in external storage it would be > helpful to allow Index implementation to distingusing between reindex and > first time index > For more details refer to http://markmail.org/message/uua3plot5qpkaqt7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2173) Allow specifying custom attributes in IndexPlan
[ https://issues.apache.org/jira/browse/OAK-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-2173. -- Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 Integrated to branch 1.0 in http://svn.apache.org/r1635660 > Allow specifying custom attributes in IndexPlan > > > Key: OAK-2173 > URL: https://issues.apache.org/jira/browse/OAK-2173 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.0.8, 1.1.2 > > Attachments: OAK-2173.patch > > > For some cases its desriable to pass custom attribute as part of IndexPlan > that is constructed by a QueryIndex implementation. For example in Lucene (as > discussed here [1]) there is a requirement to communicate the index path as > part of IndexPlan such that index implementation can acquire the right index > for the query > [1] http://markmail.org/thread/ajhh6sn3evt46pza -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-1980) Use index on non-root node
[ https://issues.apache.org/jira/browse/OAK-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191272#comment-14191272 ] Chetan Mehrotra commented on OAK-1980: -- With http://svn.apache.org/r1635658 I have pulled in changes done in QueryIndex via patch > Use index on non-root node > -- > > Key: OAK-1980 > URL: https://issues.apache.org/jira/browse/OAK-1980 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Marcel Reutegger >Assignee: Davide Giannella > Fix For: 1.2 > > Attachments: OAK-1980.patch > > > Oak is able to maintain indexes on any location in the hierarchy. However the > lookup for most index implementations only make use of an index under the > root node. There are various TODOs in the code regarding this, e.g. in > PropertyIndex. Looking up an index along the filter path adds some additional > cost, but should be within reasonable bounds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2240) Support for indexing relative properties
[
https://issues.apache.org/jira/browse/OAK-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190619#comment-14190619
]
Alex Parvulescu commented on OAK-2240:
--
added support for a max levels deep traversal based on the relative properties
definition: http://svn.apache.org/r1635586
[~chetanm] please review!
> Support for indexing relative properties
>
>
> Key: OAK-2240
> URL: https://issues.apache.org/jira/browse/OAK-2240
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.2
>
> Attachments: LuceneIndexEditor.java.patch, OAK-2240-test-rm.patch,
> OAK-2240.patch
>
>
> Lucene property index needs to support following queries which make use of
> relative properties
> {noformat}
> select [jcr:path], [jcr:score], * from [dam:Asset] as a
> where [jcr:content/jcr:lastModified] > cast('2014-10-01T00:00:00.000+02:00'
> as date)
> {noformat}
> Possible Approach
> # Have the index definition define a property like foo/bar
> # LuceneIndexEditor would also index child property foo/bar as part of parent
> node if present
> # On update in child the child node can indicate the parent to make the
> document again
> # On query side the property restriction can be used listerall i.e. foo/bar
> and stuff should work fine
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2240) Support for indexing relative properties
[
https://issues.apache.org/jira/browse/OAK-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190501#comment-14190501
]
Chetan Mehrotra commented on OAK-2240:
--
Thanks Alex I have applied the updated patch which includes your changes. So
next pending thing is to reduce the traversal in deleted subtree to max depth
of configured relative paths
@Thomas - I have removed the dummy test and left a TODO to take care of invalid
property names
> Support for indexing relative properties
>
>
> Key: OAK-2240
> URL: https://issues.apache.org/jira/browse/OAK-2240
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.2
>
> Attachments: LuceneIndexEditor.java.patch, OAK-2240-test-rm.patch,
> OAK-2240.patch
>
>
> Lucene property index needs to support following queries which make use of
> relative properties
> {noformat}
> select [jcr:path], [jcr:score], * from [dam:Asset] as a
> where [jcr:content/jcr:lastModified] > cast('2014-10-01T00:00:00.000+02:00'
> as date)
> {noformat}
> Possible Approach
> # Have the index definition define a property like foo/bar
> # LuceneIndexEditor would also index child property foo/bar as part of parent
> node if present
> # On update in child the child node can indicate the parent to make the
> document again
> # On query side the property restriction can be used listerall i.e. foo/bar
> and stuff should work fine
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2234) Support property existence query
[
https://issues.apache.org/jira/browse/OAK-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190367#comment-14190367
]
Tommaso Teofili commented on OAK-2234:
--
fyi: http://markmail.org/message/kheqlwqrurquc36y
> Support property existence query
>
>
> Key: OAK-2234
> URL: https://issues.apache.org/jira/browse/OAK-2234
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.0.8, 1.2
>
>
> Add support for property existence query like
> {noformat}
> select [jcr:path] from [nt:base] where propa is not null
> {noformat}
> Opposite of this cannot be be supported i.e. {{propa is null}} though!
> With OAK-1208 query creation logic explicitly ignores such queries but with
> recent Lucene changes it appears to be possible LUCENE-995
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2240) Support for indexing relative properties
[
https://issues.apache.org/jira/browse/OAK-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-2240:
-
Attachment: LuceneIndexEditor.java.patch
attaching proposed update for the index editor that passes the remove test
> Support for indexing relative properties
>
>
> Key: OAK-2240
> URL: https://issues.apache.org/jira/browse/OAK-2240
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.2
>
> Attachments: LuceneIndexEditor.java.patch, OAK-2240-test-rm.patch,
> OAK-2240.patch
>
>
> Lucene property index needs to support following queries which make use of
> relative properties
> {noformat}
> select [jcr:path], [jcr:score], * from [dam:Asset] as a
> where [jcr:content/jcr:lastModified] > cast('2014-10-01T00:00:00.000+02:00'
> as date)
> {noformat}
> Possible Approach
> # Have the index definition define a property like foo/bar
> # LuceneIndexEditor would also index child property foo/bar as part of parent
> node if present
> # On update in child the child node can indicate the parent to make the
> document again
> # On query side the property restriction can be used listerall i.e. foo/bar
> and stuff should work fine
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2198) Add support for declaringNodeTypes to only index node with specific types
[ https://issues.apache.org/jira/browse/OAK-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14186477#comment-14186477 ] Amit Jain edited comment on OAK-2198 at 10/30/14 3:33 PM: -- Committed the patch in trunk with revision http://svn.apache.org/r1634792 was (Author: amitjain): Committed the patch with revision http://svn.apache.org/r1634792 > Add support for declaringNodeTypes to only index node with specific types > - > > Key: OAK-2198 > URL: https://issues.apache.org/jira/browse/OAK-2198 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: oak-lucene >Reporter: Chetan Mehrotra >Assignee: Amit Jain > Fix For: 1.0.8, 1.1.2 > > Attachments: OAK-2198.patch > > > Add support for declaringNodeTypes to only index node with specific types. > Also have a look at OAK-388 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2241) Support native queries for non-full-text indexes
[ https://issues.apache.org/jira/browse/OAK-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2241: -- Fix Version/s: (was: 1.1.2) 1.1.3 > Support native queries for non-full-text indexes > > > Key: OAK-2241 > URL: https://issues.apache.org/jira/browse/OAK-2241 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.2, 1.1.3 > > > Currently, native queries are only supported for full-text indexes. The > LuceneProperty index would also benefit from that. So I think we need to add > a new marker interface, NativeQueryIndex, so we can support it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2242) provide a way to update the "created" timestamp of a NodeDocument
[ https://issues.apache.org/jira/browse/OAK-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2242: -- Fix Version/s: (was: 1.1.2) 1.2 > provide a way to update the "created" timestamp of a NodeDocument > - > > Key: OAK-2242 > URL: https://issues.apache.org/jira/browse/OAK-2242 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Affects Versions: 1.1.1 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.2 > > > Both the MongoDocumentStore and the RDBDocumentStore maintain a "_modCount" > property, which uniquely identifies a version of a document in the > persistence. > Sometimes, we read data from the persistence although we already might have > the document cached. This happens: > a) when the cached document is older than what the caller asked for > b) when running a query (for instance when looking up children of a node) > In both cases, we currently replace the cache entry with a newly built > NodeDocument. > It would make sense to re-use the existing document instead. (This would > probably require modifying the "created" timestamp, but would avoid the > trouble of having to update the cache at all) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2220) Support for atomic counters
[ https://issues.apache.org/jira/browse/OAK-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-2220: -- Fix Version/s: (was: 1.1.2) 1.2 > Support for atomic counters > --- > > Key: OAK-2220 > URL: https://issues.apache.org/jira/browse/OAK-2220 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: Michael Dürig >Assignee: Michael Dürig > Fix For: 1.2 > > > For several use cases (think +1/-1 votes on forum posts) it would be good to > have some basic support for atomic counters in Oak. Such counters must: > # correctly reflect increments/decrements by integral parts across threads / > cluster nodes, > # exhibit some well defined consistency characteristics amongst each other, > # not require cluster wide coordination. > 1. is required so in the forum post example the correct number of votes is > recorded for each post. > 2. is important so in the forum post example sorting by votes results in the > correct order. > 3. is important as global cluster synchronisation run contrary to out overall > scalability goals. > Additionally such counters should allow the user to trade off the consistency > characteristics from 2 for availability. I.e. scarifying some availability > results in hight consistency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2223) IndexStatsMBean should not reset start time
[ https://issues.apache.org/jira/browse/OAK-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved OAK-2223. -- Resolution: Duplicate Fix Version/s: (was: 1.1.2) fixed via OAK-2230 > IndexStatsMBean should not reset start time > --- > > Key: OAK-2223 > URL: https://issues.apache.org/jira/browse/OAK-2223 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu >Priority: Minor > > Currently the IndexStatsMBean will reset the start time of an indexing cycle > whenever it finishes. This introduces an interesting problem when you need to > observe the indexing process. There's no real way of knowing if the cycle > that finished after you started observing it started or not before that > moment. > Ex: > -- (t1) - (t2) - (t1') (t3) --> > Let's assume an observer starts reading the indexing stats at (t2) and > notices only the end time at (t3). Here we have a race condition: if the > indexing cycle started at (t1) then the search should work but if the cycle > actually started at (t1') the search won't work. > Long story short, let's not reset the start time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2222) Clarify the OakIndexFile input and output contracts
[ https://issues.apache.org/jira/browse/OAK-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-: - Fix Version/s: (was: 1.1.2) 1.2 > Clarify the OakIndexFile input and output contracts > --- > > Key: OAK- > URL: https://issues.apache.org/jira/browse/OAK- > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-lucene >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu >Priority: Minor > Fix For: 1.2 > > Attachments: lucene-directory.patch > > > This is just a minor refactoring of the current code to clarify that the > _OakIndexInput_ is in fact a read-only view. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2240) Support for indexing relative properties
[
https://issues.apache.org/jira/browse/OAK-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-2240:
-
Attachment: OAK-2240-test-rm.patch
Another issue with the current code is that is doesn't update the parent nodes
in the case of deletes. I think this is pretty important, as it can introduce
false hits. attached an updated test case.
> Support for indexing relative properties
>
>
> Key: OAK-2240
> URL: https://issues.apache.org/jira/browse/OAK-2240
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.2
>
> Attachments: OAK-2240-test-rm.patch, OAK-2240.patch
>
>
> Lucene property index needs to support following queries which make use of
> relative properties
> {noformat}
> select [jcr:path], [jcr:score], * from [dam:Asset] as a
> where [jcr:content/jcr:lastModified] > cast('2014-10-01T00:00:00.000+02:00'
> as date)
> {noformat}
> Possible Approach
> # Have the index definition define a property like foo/bar
> # LuceneIndexEditor would also index child property foo/bar as part of parent
> node if present
> # On update in child the child node can indicate the parent to make the
> document again
> # On query side the property restriction can be used listerall i.e. foo/bar
> and stuff should work fine
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2242) provide a way to update the "created" timestamp of a NodeDocument
[ https://issues.apache.org/jira/browse/OAK-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190098#comment-14190098 ] Julian Reschke commented on OAK-2242: - Turns out that NodeDocument indeed supports something like this, but it's not getCreated() but getLastCheckTime(). However, both the RDB and the Mongo persistence use getCreated() to check whether an entry found in the cache can be used. Is *that* the problem we need to fix? > provide a way to update the "created" timestamp of a NodeDocument > - > > Key: OAK-2242 > URL: https://issues.apache.org/jira/browse/OAK-2242 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Affects Versions: 1.1.1 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.1.2 > > > Both the MongoDocumentStore and the RDBDocumentStore maintain a "_modCount" > property, which uniquely identifies a version of a document in the > persistence. > Sometimes, we read data from the persistence although we already might have > the document cached. This happens: > a) when the cached document is older than what the caller asked for > b) when running a query (for instance when looking up children of a node) > In both cases, we currently replace the cache entry with a newly built > NodeDocument. > It would make sense to re-use the existing document instead. (This would > probably require modifying the "created" timestamp, but would avoid the > trouble of having to update the cache at all) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2245) UserImporter should always set the rep:authorizableID
[ https://issues.apache.org/jira/browse/OAK-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189932#comment-14189932 ] angela edited comment on OAK-2245 at 10/30/14 1:55 PM: --- rev. 1635464 (and rev. 1635494 for the CugImporter, thanks [~julian.resc...@gmx.de] for spotting the missing piece!) was (Author: anchela): rev. 1635464 > UserImporter should always set the rep:authorizableID > - > > Key: OAK-2245 > URL: https://issues.apache.org/jira/browse/OAK-2245 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: angela >Assignee: angela > Fix For: 1.1.2 > > Attachments: OAK-2245.patch, oak-2245-additional-tests.patch > > > upon XML import of user/group nodes the UserImporter currently doesn't > enforce the creation of rep:authorizableID which has been introduced with Oak > 1.0. > while this allows to import JR 2.x content packages as they are, it will > cause the import to fail in case of uuid-conflicts with existing > authorizables at a different location. > for this reason and in order to make sure that imported user/group content > always has the authorizableID set, we should change the user importer to > verify that an authorizable id property has been imported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2240) Support for indexing relative properties
[
https://issues.apache.org/jira/browse/OAK-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190065#comment-14190065
]
Alex Parvulescu commented on OAK-2240:
--
it looks like the current version is a bit eager in marking the parent indexers
as dirty in the case there's no match on the relative path.
Here's an improved version of the _markParentsOnRelPropChange_ method:
{code}
private void markParentsOnRelPropChange() {
for (RelativeProperty rp : changedRelativeProps) {
LuceneIndexEditor p = this;
for (String parentName : rp.ancestors) {
if (p == null || !p.name.equals(parentName)) {
p = null;
break;
}
p = p.parent;
}
if (p != null) {
p.markPropertiesChanged();
}
}
}
{code}
Changes are: _LuceneIndexEditor p = this;_ and _p = null_ .
> Support for indexing relative properties
>
>
> Key: OAK-2240
> URL: https://issues.apache.org/jira/browse/OAK-2240
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.2
>
> Attachments: OAK-2240.patch
>
>
> Lucene property index needs to support following queries which make use of
> relative properties
> {noformat}
> select [jcr:path], [jcr:score], * from [dam:Asset] as a
> where [jcr:content/jcr:lastModified] > cast('2014-10-01T00:00:00.000+02:00'
> as date)
> {noformat}
> Possible Approach
> # Have the index definition define a property like foo/bar
> # LuceneIndexEditor would also index child property foo/bar as part of parent
> node if present
> # On update in child the child node can indicate the parent to make the
> document again
> # On query side the property restriction can be used listerall i.e. foo/bar
> and stuff should work fine
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2240) Support for indexing relative properties
[
https://issues.apache.org/jira/browse/OAK-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190054#comment-14190054
]
Thomas Mueller commented on OAK-2240:
-
I'm not familiar with this part of the Lucene index. A few things I noticed:
Minor: isRelativeProperty also checks "!PathUtils.isAbsolute". How can an
absolute path be indexed... I think it would be better to reject absolute path
and other strange property names (empty names for example).
Minor: there is a strange test "bool()", could be removed (it has a System.out).
> Support for indexing relative properties
>
>
> Key: OAK-2240
> URL: https://issues.apache.org/jira/browse/OAK-2240
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.2
>
> Attachments: OAK-2240.patch
>
>
> Lucene property index needs to support following queries which make use of
> relative properties
> {noformat}
> select [jcr:path], [jcr:score], * from [dam:Asset] as a
> where [jcr:content/jcr:lastModified] > cast('2014-10-01T00:00:00.000+02:00'
> as date)
> {noformat}
> Possible Approach
> # Have the index definition define a property like foo/bar
> # LuceneIndexEditor would also index child property foo/bar as part of parent
> node if present
> # On update in child the child node can indicate the parent to make the
> document again
> # On query side the property restriction can be used listerall i.e. foo/bar
> and stuff should work fine
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2245) UserImporter should always set the rep:authorizableID
[ https://issues.apache.org/jira/browse/OAK-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-2245. - Resolution: Fixed Fix Version/s: 1.1.2 rev. 1635464 > UserImporter should always set the rep:authorizableID > - > > Key: OAK-2245 > URL: https://issues.apache.org/jira/browse/OAK-2245 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: angela >Assignee: angela > Fix For: 1.1.2 > > Attachments: OAK-2245.patch, oak-2245-additional-tests.patch > > > upon XML import of user/group nodes the UserImporter currently doesn't > enforce the creation of rep:authorizableID which has been introduced with Oak > 1.0. > while this allows to import JR 2.x content packages as they are, it will > cause the import to fail in case of uuid-conflicts with existing > authorizables at a different location. > for this reason and in order to make sure that imported user/group content > always has the authorizableID set, we should change the user importer to > verify that an authorizable id property has been imported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2245) UserImporter should always set the rep:authorizableID
[ https://issues.apache.org/jira/browse/OAK-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189803#comment-14189803 ] angela edited comment on OAK-2245 at 10/30/14 10:55 AM: hmm... but the import would then fail (irrespective on whether or not we add the rep:authorizableId property during the import)... and you have to add more magic to the fvault that knows about the implementation details of jr/oak... wouldn't it be preferable to keep it simple and document instead that this will not work? shall i add a verification to the importer instead? was (Author: anchela): hmm... but the import would then fail... and you have to add more magic to the fvault that knows about the implementation details of jr/oak... wouldn't it be preferable to keep it simple and document instead that this will not work? shall i add a verification to the importer instead? > UserImporter should always set the rep:authorizableID > - > > Key: OAK-2245 > URL: https://issues.apache.org/jira/browse/OAK-2245 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: angela >Assignee: angela > Attachments: OAK-2245.patch, oak-2245-additional-tests.patch > > > upon XML import of user/group nodes the UserImporter currently doesn't > enforce the creation of rep:authorizableID which has been introduced with Oak > 1.0. > while this allows to import JR 2.x content packages as they are, it will > cause the import to fail in case of uuid-conflicts with existing > authorizables at a different location. > for this reason and in order to make sure that imported user/group content > always has the authorizableID set, we should change the user importer to > verify that an authorizable id property has been imported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2240) Support for indexing relative properties
[
https://issues.apache.org/jira/browse/OAK-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2240:
-
Attachment: OAK-2240.patch
Initial patch to demonstrate the approach (more tests need to be added)
[~alex.parvulescu] [~tmueller] Can you review the approach
> Support for indexing relative properties
>
>
> Key: OAK-2240
> URL: https://issues.apache.org/jira/browse/OAK-2240
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.0.8, 1.2
>
> Attachments: OAK-2240.patch
>
>
> Lucene property index needs to support following queries which make use of
> relative properties
> {noformat}
> select [jcr:path], [jcr:score], * from [dam:Asset] as a
> where [jcr:content/jcr:lastModified] > cast('2014-10-01T00:00:00.000+02:00'
> as date)
> {noformat}
> Possible Approach
> # Have the index definition define a property like foo/bar
> # LuceneIndexEditor would also index child property foo/bar as part of parent
> node if present
> # On update in child the child node can indicate the parent to make the
> document again
> # On query side the property restriction can be used listerall i.e. foo/bar
> and stuff should work fine
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2234) Support property existence query
[
https://issues.apache.org/jira/browse/OAK-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189929#comment-14189929
]
Alex Parvulescu commented on OAK-2234:
--
looks good +1
The only doubts I had were about introducing a behavior that is similar to
OAK-2134, we have to guard against lucene deciding to pickup all existing
tokens for a given value and using then in the range query. this doesn't look
like it's the case here though.
> Support property existence query
>
>
> Key: OAK-2234
> URL: https://issues.apache.org/jira/browse/OAK-2234
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: oak-lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.0.8, 1.2
>
>
> Add support for property existence query like
> {noformat}
> select [jcr:path] from [nt:base] where propa is not null
> {noformat}
> Opposite of this cannot be be supported i.e. {{propa is null}} though!
> With OAK-1208 query creation logic explicitly ignores such queries but with
> recent Lucene changes it appears to be possible LUCENE-995
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2248) IndexOutOfBoundsException in o.a.j.o.scalability.ScalabilityNodeRelationshipSuite
[
https://issues.apache.org/jira/browse/OAK-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella resolved OAK-2248.
---
Resolution: Fixed
Fix Version/s: 1.1.2
Fixed in trunk @ http://svn.apache.org/r1635458
> IndexOutOfBoundsException in
> o.a.j.o.scalability.ScalabilityNodeRelationshipSuite
> -
>
> Key: OAK-2248
> URL: https://issues.apache.org/jira/browse/OAK-2248
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Labels: scalability
> Fix For: 1.2, 1.1.2
>
>
> When running the scalability suite even if not run the
> org.apache.jackrabbit.oak.scalability.ScalabilityNodeRelationshipSuite fails
> with
> {noformat}
> Apache Jackrabbit Oak
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at
> org.apache.jackrabbit.oak.scalability.ScalabilityRunner.main(ScalabilityRunner.java:143)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:162)
> Caused by: java.lang.IndexOutOfBoundsException: Index: 3, Size: 3
> at java.util.ArrayList.RangeCheck(ArrayList.java:547)
> at java.util.ArrayList.get(ArrayList.java:322)
> at java.util.Collections$UnmodifiableList.get(Collections.java:1152)
> at
> org.apache.jackrabbit.oak.scalability.ScalabilityNodeRelationshipSuite.(ScalabilityNodeRelationshipSuite.java:89)
> ... 2 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2248) IndexOutOfBoundsException in o.a.j.o.scalability.ScalabilityNodeRelationshipSuite
Davide Giannella created OAK-2248:
-
Summary: IndexOutOfBoundsException in
o.a.j.o.scalability.ScalabilityNodeRelationshipSuite
Key: OAK-2248
URL: https://issues.apache.org/jira/browse/OAK-2248
Project: Jackrabbit Oak
Issue Type: Bug
Affects Versions: 1.2
Reporter: Davide Giannella
Assignee: Davide Giannella
Fix For: 1.2
When running the scalability suite even if not run the
org.apache.jackrabbit.oak.scalability.ScalabilityNodeRelationshipSuite fails
with
{noformat}
Apache Jackrabbit Oak
Exception in thread "main" java.lang.ExceptionInInitializerError
at
org.apache.jackrabbit.oak.scalability.ScalabilityRunner.main(ScalabilityRunner.java:143)
at org.apache.jackrabbit.oak.run.Main.main(Main.java:162)
Caused by: java.lang.IndexOutOfBoundsException: Index: 3, Size: 3
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at java.util.Collections$UnmodifiableList.get(Collections.java:1152)
at
org.apache.jackrabbit.oak.scalability.ScalabilityNodeRelationshipSuite.(ScalabilityNodeRelationshipSuite.java:89)
... 2 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-2230) Execution Stats for async indexing
[ https://issues.apache.org/jira/browse/OAK-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-2230. Resolution: Fixed Removed custom executor from AsyncIndexStats#ExecutionStats due to OOME in test execution with MongoDB and RDB fixtures with commit http://svn.apache.org/r1635436 > Execution Stats for async indexing > -- > > Key: OAK-2230 > URL: https://issues.apache.org/jira/browse/OAK-2230 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Amit Jain >Assignee: Amit Jain > Fix For: 1.1.2 > > Attachments: OAK-2230.patch > > > Add execution stats for async indexing. This should help in monitoring the > total execution time, number of nodes indexed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2245) UserImporter should always set the rep:authorizableID
[ https://issues.apache.org/jira/browse/OAK-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189803#comment-14189803 ] angela commented on OAK-2245: - hmm... but the import would then fail... and you have to add more magic to the fvault that knows about the implementation details of jr/oak... wouldn't it be preferable to keep it simple and document instead that this will not work? shall i add a verification to the importer instead? > UserImporter should always set the rep:authorizableID > - > > Key: OAK-2245 > URL: https://issues.apache.org/jira/browse/OAK-2245 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: angela >Assignee: angela > Attachments: OAK-2245.patch, oak-2245-additional-tests.patch > > > upon XML import of user/group nodes the UserImporter currently doesn't > enforce the creation of rep:authorizableID which has been introduced with Oak > 1.0. > while this allows to import JR 2.x content packages as they are, it will > cause the import to fail in case of uuid-conflicts with existing > authorizables at a different location. > for this reason and in order to make sure that imported user/group content > always has the authorizableID set, we should change the user importer to > verify that an authorizable id property has been imported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2245) UserImporter should always set the rep:authorizableID
[ https://issues.apache.org/jira/browse/OAK-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189778#comment-14189778 ] Tobias Bocanegra commented on OAK-2245: --- you are right. I added a workaround in FileVault in case a package with jr users is installed with ImportMode.Update into a oak repository with modified node names. in this case vault wants to preserve the node name. > UserImporter should always set the rep:authorizableID > - > > Key: OAK-2245 > URL: https://issues.apache.org/jira/browse/OAK-2245 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: angela >Assignee: angela > Attachments: OAK-2245.patch, oak-2245-additional-tests.patch > > > upon XML import of user/group nodes the UserImporter currently doesn't > enforce the creation of rep:authorizableID which has been introduced with Oak > 1.0. > while this allows to import JR 2.x content packages as they are, it will > cause the import to fail in case of uuid-conflicts with existing > authorizables at a different location. > for this reason and in order to make sure that imported user/group content > always has the authorizableID set, we should change the user importer to > verify that an authorizable id property has been imported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2245) UserImporter should always set the rep:authorizableID
[ https://issues.apache.org/jira/browse/OAK-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189768#comment-14189768 ] angela commented on OAK-2245: - [~tripod], thanks a lot. regarding the problem you found: a jr2 user node that has been renamed is broken anyway. importing this node as is will in any case fail as the uuid doesn't match the id (this is verified in the commit hook) and in jr2 the only way to obtain the ID string was the node name... so, i don't consider this a realistic scenario. it was different if simply moving (but not renaming) the node would have the same effect. wdyt? > UserImporter should always set the rep:authorizableID > - > > Key: OAK-2245 > URL: https://issues.apache.org/jira/browse/OAK-2245 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: angela >Assignee: angela > Attachments: OAK-2245.patch, oak-2245-additional-tests.patch > > > upon XML import of user/group nodes the UserImporter currently doesn't > enforce the creation of rep:authorizableID which has been introduced with Oak > 1.0. > while this allows to import JR 2.x content packages as they are, it will > cause the import to fail in case of uuid-conflicts with existing > authorizables at a different location. > for this reason and in order to make sure that imported user/group content > always has the authorizableID set, we should change the user importer to > verify that an authorizable id property has been imported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2138) Alternative implementation of AuthorizableNodeName interface
[ https://issues.apache.org/jira/browse/OAK-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-2138. - Resolution: Fixed Fix Version/s: (was: 1.2) 1.1.2 the feature is a osgi service that mandatory requires a configuration in order to be activated. for java based repository setup an instance of the RandomAuthorizableNodeName neeeds to be put into the user configuration. > Alternative implementation of AuthorizableNodeName interface > > > Key: OAK-2138 > URL: https://issues.apache.org/jira/browse/OAK-2138 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: angela >Assignee: angela > Fix For: 1.1.2 > > > it would be desirable to provide an alternative implementation of the > AuthorizableNodeName interface that doesn't generate predictable node > name/path. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
