[jira] [Commented] (SOLR-8347) Asynchronous searcher for custom component
[
https://issues.apache.org/jira/browse/SOLR-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037840#comment-15037840
]
Bogdan Marinescu commented on SOLR-8347:
I made it a blocker because nobody was answering. It's not a blocker but it is
I believe an issue because if I want to do some asynchronous work in a custom
component I cannot access the SolrIndexSearcher anymore.. mainly because after
the solr call is over someone/something closes the searcher (probably due to a
commit). I was wondering if what I was trying to do was possible (to lock the
searcher somehow until my component releases it) but I'll take your advice and
ask in the solr user list
> Asynchronous searcher for custom component
> --
>
> Key: SOLR-8347
> URL: https://issues.apache.org/jira/browse/SOLR-8347
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Reporter: Bogdan Marinescu
>Priority: Critical
>
> I'm trying to write a custom component for fuzzy searches.
> After solr calls my component, I create a Thread and give it the
> SolrIndexSearcher and some params.
> Problem is after a few seconds I get an Exception that the indexreader was
> closed
> {code}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be
> used anymore as one of its child readers was closed
> at
> org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
> at
> org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
> at
> awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
> at
> awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Is there a way of locking the IndexReader so it doesn't get closed by other
> threads?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8347) Asynchronous searcher for custom component
[
https://issues.apache.org/jira/browse/SOLR-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Marinescu updated SOLR-8347:
---
Priority: Critical (was: Blocker)
> Asynchronous searcher for custom component
> --
>
> Key: SOLR-8347
> URL: https://issues.apache.org/jira/browse/SOLR-8347
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Reporter: Bogdan Marinescu
>Priority: Critical
>
> I'm trying to write a custom component for fuzzy searches.
> After solr calls my component, I create a Thread and give it the
> SolrIndexSearcher and some params.
> Problem is after a few seconds I get an Exception that the indexreader was
> closed
> {code}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be
> used anymore as one of its child readers was closed
> at
> org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
> at
> org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
> at
> awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
> at
> awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Is there a way of locking the IndexReader so it doesn't get closed by other
> threads?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8347) Asynchronous searcher for custom component
[
https://issues.apache.org/jira/browse/SOLR-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Marinescu updated SOLR-8347:
---
Priority: Blocker (was: Major)
Would be cool if someone answered...
> Asynchronous searcher for custom component
> --
>
> Key: SOLR-8347
> URL: https://issues.apache.org/jira/browse/SOLR-8347
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Reporter: Bogdan Marinescu
>Priority: Blocker
>
> I'm trying to write a custom component for fuzzy searches.
> After solr calls my component, I create a Thread and give it the
> SolrIndexSearcher and some params.
> Problem is after a few seconds I get an Exception that the indexreader was
> closed
> {code}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be
> used anymore as one of its child readers was closed
> at
> org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
> at
> org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
> at
> awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
> at
> awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Is there a way of locking the IndexReader so it doesn't get closed by other
> threads?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8347) Asynchronous searcher for custom component
[
https://issues.apache.org/jira/browse/SOLR-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Marinescu updated SOLR-8347:
---
Description:
I'm trying to write a custom component for fuzzy searches.
After solr calls my component, I create a Thread and give it the
SolrIndexSearcher and some params.
Problem is after a few seconds I get an Exception that the indexreader was
closed
{code}
org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be used
anymore as one of its child readers was closed
at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
at
org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
at
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
at
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
at
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
at
org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
at
awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
at awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Is there a way of locking the IndexReader so it doesn't get closed by other
threads?
was:
I'm trying to write a custom component for fuzzy searches.
After solr calls my component, I create a Thread and give it the
SolrIndexSearcher and some params.
Problem is after a few seconds I get an Exception that the indexreader was
closed
{code}
rg.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be used
anymore as one of its child readers was closed
at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
at
org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
at
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
at
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
at
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
at
org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
at
awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
at awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Is there a way of locking the IndexReader so it doesn't get closed by other
threads?
> Asynchronous searcher for custom component
> --
>
> Key: SOLR-8347
> URL: https://issues.apache.org/jira/browse/SOLR-8347
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Reporter: Bogdan Marinescu
>
> I'm trying to write a custom component for fuzzy searches.
> After solr calls my component, I create a Thread and give it the
> SolrIndexSearcher and some params.
> Problem is after a few seconds I get an Exception that the indexreader was
> closed
> {code}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be
> used anymore as one of its child readers was closed
> at
> org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
> at
> org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.jav
[jira] [Created] (SOLR-8347) Asynchronous searcher for custom component
Bogdan Marinescu created SOLR-8347:
--
Summary: Asynchronous searcher for custom component
Key: SOLR-8347
URL: https://issues.apache.org/jira/browse/SOLR-8347
Project: Solr
Issue Type: Bug
Components: SearchComponents - other
Reporter: Bogdan Marinescu
I'm trying to write a custom component for fuzzy searches.
After solr calls my component, I create a Thread and give it the
SolrIndexSearcher and some params.
Problem is after a few seconds I get an Exception that the indexreader was
closed
{code}
rg.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be used
anymore as one of its child readers was closed
at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
at
org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
at
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
at
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
at
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
at
org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
at
awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
at awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Is there a way of locking the IndexReader so it doesn't get closed by other
threads?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7351) MoreLikeThis component doesn't work with dates
[
https://issues.apache.org/jira/browse/SOLR-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482708#comment-14482708
]
Bogdan Marinescu commented on SOLR-7351:
I started writing my own MoreLikeThis like component which also performs fuzzy
searches. As I understand it from SOLR-4860, another limitation would be
numbers (solr.TrieIntField &co).
Can you perhaps think of a generic solution for this or should I just keep
digging 'till I find something ?
> MoreLikeThis component doesn't work with dates
> --
>
> Key: SOLR-7351
> URL: https://issues.apache.org/jira/browse/SOLR-7351
> Project: Solr
> Issue Type: Bug
> Components: MoreLikeThis
>Affects Versions: 5.0
>Reporter: Bogdan Marinescu
>Priority: Critical
>
> A simple query on an index which has a TrieDate (at least this is my date
> type)
> {code}
>
> ...
> positionIncrementGap="0"/>
> {code}
> Query for:
> http://localhost:8983/solr/tj13/select?q=testDate_dt%3A%221948-09-28T22%3A00%3A00Z%22&wt=json&indent=true&mlt=true&mlt.fl=testDate_dt
> results in:
> {code}
> ERROR - 2015-04-06 08:36:52.059; org.apache.solr.common.SolrException;
> org.apache.solr.common.SolrException: Invalid Date String:'-67081680'
> at
> org.apache.solr.schema.TrieDateField.parseMath(TrieDateField.java:150)
> at
> org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:436)
> at
> org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:414)
> at org.apache.solr.schema.TrieField.toInternal(TrieField.java:449)
> at
> org.apache.solr.schema.FieldType$DefaultAnalyzer$1.incrementToken(FieldType.java:484)
> at
> org.apache.lucene.queries.mlt.MoreLikeThis.addTermFrequencies(MoreLikeThis.java:822)
> at
> org.apache.lucene.queries.mlt.MoreLikeThis.retrieveTerms(MoreLikeThis.java:745)
> at
> org.apache.lucene.queries.mlt.MoreLikeThis.like(MoreLikeThis.java:586)
> at
> org.apache.solr.handler.MoreLikeThisHandler$MoreLikeThisHelper.getMoreLikeThis(MoreLikeThisHandler.java:374)
> at
> org.apache.solr.handler.component.MoreLikeThisComponent.getMoreLikeThese(MoreLikeThisComponent.java:370)
> at
> org.apache.solr.handler.component.MoreLikeThisComponent.process(MoreLikeThisComponent.java:123)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:227)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:368)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
> at
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
> at
> org.eclipse.jetty.http.HttpParser.par
[jira] [Updated] (SOLR-7351) MoreLikeThis component doesn't work with dates
[
https://issues.apache.org/jira/browse/SOLR-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Marinescu updated SOLR-7351:
---
Description:
A simple query on an index which has a TrieDate (at least this is my date type)
{code}
...
{code}
Query for:
http://localhost:8983/solr/tj13/select?q=testDate_dt%3A%221948-09-28T22%3A00%3A00Z%22&wt=json&indent=true&mlt=true&mlt.fl=testDate_dt
results in:
{code}
ERROR - 2015-04-06 08:36:52.059; org.apache.solr.common.SolrException;
org.apache.solr.common.SolrException: Invalid Date String:'-67081680'
at
org.apache.solr.schema.TrieDateField.parseMath(TrieDateField.java:150)
at
org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:436)
at
org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:414)
at org.apache.solr.schema.TrieField.toInternal(TrieField.java:449)
at
org.apache.solr.schema.FieldType$DefaultAnalyzer$1.incrementToken(FieldType.java:484)
at
org.apache.lucene.queries.mlt.MoreLikeThis.addTermFrequencies(MoreLikeThis.java:822)
at
org.apache.lucene.queries.mlt.MoreLikeThis.retrieveTerms(MoreLikeThis.java:745)
at
org.apache.lucene.queries.mlt.MoreLikeThis.like(MoreLikeThis.java:586)
at
org.apache.solr.handler.MoreLikeThisHandler$MoreLikeThisHelper.getMoreLikeThis(MoreLikeThisHandler.java:374)
at
org.apache.solr.handler.component.MoreLikeThisComponent.getMoreLikeThese(MoreLikeThisComponent.java:370)
at
org.apache.solr.handler.component.MoreLikeThisComponent.process(MoreLikeThisComponent.java:123)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:227)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
{code}
I think it's weird that solr has the correct date, gives a long to the
MoreLikeThis component and when the tokenizer tries to parse the date it throws
an exception.
was:
A simple query on an index which has a TrieDate (at least this is my date type)
{code}
...
{code}
Query for:
http://localhost:8983/solr/tj13/select?q=testDate_dt%3A%221948-09-28T22%3A00%3A00Z%22&wt=json&indent=true&mlt=true&mlt.fl=testDate_dt
results in:
{code}
ERROR -
[jira] [Updated] (SOLR-7351) MoreLikeThis component doesn't work with dates
[
https://issues.apache.org/jira/browse/SOLR-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Marinescu updated SOLR-7351:
---
Description:
A simple query on an index which has a TrieDate (at least this is my date type)
{code}
...
{code}
Query for:
http://localhost:8983/solr/tj13/select?q=testDate_dt%3A%221948-09-28T22%3A00%3A00Z%22&wt=json&indent=true&mlt=true&mlt.fl=testDate_dt
results in:
{code}
ERROR - 2015-04-06 08:36:52.059; org.apache.solr.common.SolrException;
org.apache.solr.common.SolrException: Invalid Date String:'-67081680'
at
org.apache.solr.schema.TrieDateField.parseMath(TrieDateField.java:150)
at
org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:436)
at
org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:414)
at org.apache.solr.schema.TrieField.toInternal(TrieField.java:449)
at
org.apache.solr.schema.FieldType$DefaultAnalyzer$1.incrementToken(FieldType.java:484)
at
org.apache.lucene.queries.mlt.MoreLikeThis.addTermFrequencies(MoreLikeThis.java:822)
at
org.apache.lucene.queries.mlt.MoreLikeThis.retrieveTerms(MoreLikeThis.java:745)
at
org.apache.lucene.queries.mlt.MoreLikeThis.like(MoreLikeThis.java:586)
at
org.apache.solr.handler.MoreLikeThisHandler$MoreLikeThisHelper.getMoreLikeThis(MoreLikeThisHandler.java:374)
at
org.apache.solr.handler.component.MoreLikeThisComponent.getMoreLikeThese(MoreLikeThisComponent.java:370)
at
org.apache.solr.handler.component.MoreLikeThisComponent.process(MoreLikeThisComponent.java:123)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:227)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
{code}
was:
A simple query on an index which has a TrieDate (at least this is my date type)
{code}
...
{code}
Query for:
http://localhost:8983/solr/tj13/select?q=testDate_dt%3A%221948-09-28T22%3A00%3A00Z%22&wt=json&indent=true&mlt=true&mlt.fl=
testDate_dt
results in:
{code}
ERROR - 2015-04-06 08:36:52.059; org.apache.solr.common.SolrException;
org.apache.solr.common.SolrException: Invalid Date String:'-67081680'
at
org.apache.solr
[jira] [Created] (SOLR-7351) MoreLikeThis component doesn't work with dates
Bogdan Marinescu created SOLR-7351:
--
Summary: MoreLikeThis component doesn't work with dates
Key: SOLR-7351
URL: https://issues.apache.org/jira/browse/SOLR-7351
Project: Solr
Issue Type: Bug
Components: MoreLikeThis
Affects Versions: 5.0
Reporter: Bogdan Marinescu
Priority: Critical
A simple query on an index which has a TrieDate (at least this is my date type)
{code}
...
{code}
Query for:
http://localhost:8983/solr/tj13/select?q=testDate_dt%3A%221948-09-28T22%3A00%3A00Z%22&wt=json&indent=true&mlt=true&mlt.fl=
testDate_dt
results in:
{code}
ERROR - 2015-04-06 08:36:52.059; org.apache.solr.common.SolrException;
org.apache.solr.common.SolrException: Invalid Date String:'-67081680'
at
org.apache.solr.schema.TrieDateField.parseMath(TrieDateField.java:150)
at
org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:436)
at
org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:414)
at org.apache.solr.schema.TrieField.toInternal(TrieField.java:449)
at
org.apache.solr.schema.FieldType$DefaultAnalyzer$1.incrementToken(FieldType.java:484)
at
org.apache.lucene.queries.mlt.MoreLikeThis.addTermFrequencies(MoreLikeThis.java:822)
at
org.apache.lucene.queries.mlt.MoreLikeThis.retrieveTerms(MoreLikeThis.java:745)
at
org.apache.lucene.queries.mlt.MoreLikeThis.like(MoreLikeThis.java:586)
at
org.apache.solr.handler.MoreLikeThisHandler$MoreLikeThisHelper.getMoreLikeThis(MoreLikeThisHandler.java:374)
at
org.apache.solr.handler.component.MoreLikeThisComponent.getMoreLikeThese(MoreLikeThisComponent.java:370)
at
org.apache.solr.handler.component.MoreLikeThisComponent.process(MoreLikeThisComponent.java:123)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:227)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@
[jira] [Commented] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising solr index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481043#comment-14481043
]
Bogdan Marinescu commented on SOLR-6700:
Any ideas if this will be fixed or should I just investigate why this is
happening.
> ChildDocTransformer doesn't return correct children after updating and
> optimising solr index
>
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Critical
> Fix For: 4.10.5
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"},
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]},
> {
> "id":"1",
> "pName":"INIT",
> "entityType":1,
> "_root_":"1",
> "_version_":1483832916867809280,
> "score":1.0}]
> }}
> {code}
> As can be seen, the document with id:2 now contains the child with id:11 that
> belongs to the document with id:1.
> I haven't found any references on the web about this except
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html
> Similar issue: SOLR-6096
> Is this problem known? Is there a workaround for this?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising solr index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14390527#comment-14390527
]
Bogdan Marinescu commented on SOLR-6700:
Any idea when the 4.10.5 will be released? As I understand it, 5.1 is about to
come out and we're already playing with 5.0.0. Where exactly does 4.10.5 fit in
?
> ChildDocTransformer doesn't return correct children after updating and
> optimising solr index
>
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Critical
> Fix For: 4.10.5
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"},
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]},
> {
> "id":"1",
> "pName":"INIT",
> "entityType":1,
> "_root_":"1",
> "_version_":1483832916867809280,
> "score":1.0}]
> }}
> {code}
> As can be seen, the document with id:2 now contains the child with id:11 that
> belongs to the document with id:1.
> I haven't found any references on the web about this except
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html
> Similar issue: SOLR-6096
> Is this problem known? Is there a workaround for this?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising solr index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214396#comment-14214396
]
Bogdan Marinescu edited comment on SOLR-6700 at 11/17/14 8:48 AM:
--
Too bad because this issue doesn't allow us to use block-join queries anymore.
A rather "simple" solution for the [child] transformer is to write a doc
transformer that uses the _root_ field in order to get the children for one
parent.
It would be good if the block-join issue will be fixed.
was (Author: bogandy):
Too bad because this issue doesn't allow us to use block-join queries anymore.
A rather "simple" solution is to write a doc transformer that uses the _root_
field in order to get the children for one parent.
> ChildDocTransformer doesn't return correct children after updating and
> optimising solr index
>
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"},
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]},
> {
> "id":"1",
> "pName":"INIT",
> "entityType":1,
> "_root_":"1",
> "_version_":1483832916867809280,
> "score":1.0}]
> }}
> {code}
> As can be seen, the document with id:2 now contains the child with id:11 that
> belongs to the document with id:1.
> I haven't found any references on the web about this except
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html
> Similar issue: SOLR-6096
> Is this problem known? Is there a workaround for this?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---
[jira] [Commented] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising solr index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214396#comment-14214396
]
Bogdan Marinescu commented on SOLR-6700:
Too bad because this issue doesn't allow us to use block-join queries anymore.
A rather "simple" solution is to write a doc transformer that uses the _root_
field in order to get the children for one parent.
> ChildDocTransformer doesn't return correct children after updating and
> optimising solr index
>
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"},
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]},
> {
> "id":"1",
> "pName":"INIT",
> "entityType":1,
> "_root_":"1",
> "_version_":1483832916867809280,
> "score":1.0}]
> }}
> {code}
> As can be seen, the document with id:2 now contains the child with id:11 that
> belongs to the document with id:1.
> I haven't found any references on the web about this except
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html
> Similar issue: SOLR-6096
> Is this problem known? Is there a workaround for this?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204837#comment-14204837
]
Bogdan Marinescu edited comment on SOLR-6700 at 11/10/14 2:51 PM:
--
The {!child} only brings the children, without the parents. - no good
The expand query/component
(https://cwiki.apache.org/confluence/display/solr/Collapse+and+Expand+Results)
brings the "parents" and afterwards what seems to be a group called 'expanded'
which contains all children.
I think this is more reliable than the ChildDocTransformer as you can specify
exactly what field should be used for "expanding" (namely _root_). Problem here
is you have to match parent and children which takes a little bit of processing.
I haven't tested yet performance-wise if it's a lot worse than the
ChildDocTransformer.
I don't think anything else exists that will bring parents and children in the
same query. (especially in solrj which has a list of child documents, filled
apparently only when using the ChildDocTransformer).
What would you recommend ?
was (Author: bogandy):
The {!child} only brings the children, without the parents. - no good
The expand query
(https://cwiki.apache.org/confluence/display/solr/Collapse+and+Expand+Results)
brings the "parents" and afterwards what seems to be a group called 'expanded'
which contains all children.
I think this is more reliable than the ChildDocTransformer as you can specify
exactly what field should be used for "expanding" (namely _root_). Problem here
is you have to match parent and children which takes a little bit of processing.
I haven't tested yet performance-wise if it's a lot worse than the
ChildDocTransformer.
I don't think anything else exists that will bring parents and children in the
same query. (especially in solrj which has a list of child documents, filled
apparently only when using the ChildDocTransformer).
What would you recommend ?
> ChildDocTransformer doesn't return correct children after updating and
> optimising sol'r index
> -
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
>
[jira] [Comment Edited] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204837#comment-14204837
]
Bogdan Marinescu edited comment on SOLR-6700 at 11/10/14 2:48 PM:
--
The {!child} only brings the children, without the parents. - no good
The expand query
(https://cwiki.apache.org/confluence/display/solr/Collapse+and+Expand+Results)
brings the "parents" and afterwards what seems to be a group called 'expanded'
which contains all children.
I think this is more reliable than the ChildDocTransformer as you can specify
exactly what field should be used for "expanding" (namely _root_). Problem here
is you have to match parent and children which takes a little bit of processing.
I haven't tested yet performance-wise if it's a lot worse than the
ChildDocTransformer.
I don't think anything else exists that will bring parents and children in the
same query. (especially in solrj which has a list of child documents, filled
apparently only when using the ChildDocTransformer).
What would you recommend ?
was (Author: bogandy):
The {!child} only brings the children, without the parents. - no good
The expand query brings the "parents" and afterwards what seems to be a group
called 'expanded' which contains all children.
I think this is more reliable than the ChildDocTransformer as you can specify
exactly what field should be used for "expanding" (namely _root_). Problem here
is you have to match parent and children which takes a little bit of processing.
I haven't tested yet performance-wise if it's a lot worse than the
ChildDocTransformer.
I don't think anything else exists that will bring parents and children in the
same query. (especially in solrj which has a list of child documents, filled
apparently only when using the ChildDocTransformer).
What would you recommend ?
> ChildDocTransformer doesn't return correct children after updating and
> optimising sol'r index
> -
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
>
[jira] [Comment Edited] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204837#comment-14204837
]
Bogdan Marinescu edited comment on SOLR-6700 at 11/10/14 2:46 PM:
--
The {!child ..} only brings the children, without the parents. - no good
The expand query brings the "parents" and afterwards what seems to be a group
called 'expanded' which contains all children.
I think this is more reliable than the ChildDocTransformer as you can specify
exactly what field should be used for "expanding" (namely _root_). Problem here
is you have to match parent and children which takes a little bit of processing.
I haven't tested yet performance-wise if it's a lot worse than the
ChildDocTransformer.
I don't think anything else exists that will bring parents and children in the
same query. (especially in solrj which has a list of child documents, filled
apparently only when using the ChildDocTransformer).
What would you recommend ?
was (Author: bogandy):
The {!child} only brings the children, without the parents. - no good
The expand query brings the "parents" and afterwards what seems to be a group
called 'expanded' which contains all children.
I think this is more reliable than the ChildDocTransformer as you can specify
exactly what field should be used for "expanding" (namely _root_). Problem here
is you have to match parent and children which takes a little bit of processing.
I haven't tested yet performance-wise if it's a lot worse than the
ChildDocTransformer.
I don't think anything else exists that will bring parents and children in the
same query. (especially in solrj which has a list of child documents, filled
apparently only when using the ChildDocTransformer).
What would you recommend ?
> ChildDocTransformer doesn't return correct children after updating and
> optimising sol'r index
> -
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_versio
[jira] [Comment Edited] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204837#comment-14204837
]
Bogdan Marinescu edited comment on SOLR-6700 at 11/10/14 2:46 PM:
--
The {!child} only brings the children, without the parents. - no good
The expand query brings the "parents" and afterwards what seems to be a group
called 'expanded' which contains all children.
I think this is more reliable than the ChildDocTransformer as you can specify
exactly what field should be used for "expanding" (namely _root_). Problem here
is you have to match parent and children which takes a little bit of processing.
I haven't tested yet performance-wise if it's a lot worse than the
ChildDocTransformer.
I don't think anything else exists that will bring parents and children in the
same query. (especially in solrj which has a list of child documents, filled
apparently only when using the ChildDocTransformer).
What would you recommend ?
was (Author: bogandy):
The {!child ..} only brings the children, without the parents. - no good
The expand query brings the "parents" and afterwards what seems to be a group
called 'expanded' which contains all children.
I think this is more reliable than the ChildDocTransformer as you can specify
exactly what field should be used for "expanding" (namely _root_). Problem here
is you have to match parent and children which takes a little bit of processing.
I haven't tested yet performance-wise if it's a lot worse than the
ChildDocTransformer.
I don't think anything else exists that will bring parents and children in the
same query. (especially in solrj which has a list of child documents, filled
apparently only when using the ChildDocTransformer).
What would you recommend ?
> ChildDocTransformer doesn't return correct children after updating and
> optimising sol'r index
> -
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_versio
[jira] [Commented] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204837#comment-14204837
]
Bogdan Marinescu commented on SOLR-6700:
The {!child} only brings the children, without the parents. - no good
The expand query brings the "parents" and afterwards what seems to be a group
called 'expanded' which contains all children.
I think this is more reliable than the ChildDocTransformer as you can specify
exactly what field should be used for "expanding" (namely _root_). Problem here
is you have to match parent and children which takes a little bit of processing.
I haven't tested yet performance-wise if it's a lot worse than the
ChildDocTransformer.
I don't think anything else exists that will bring parents and children in the
same query. (especially in solrj which has a list of child documents, filled
apparently only when using the ChildDocTransformer).
What would you recommend ?
> ChildDocTransformer doesn't return correct children after updating and
> optimising sol'r index
> -
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"},
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]},
> {
> "id":"1",
> "pName":"INIT",
> "entityType":1,
> "_root_":"1",
> "_version_":1483832916867809280,
> "score":1.0}]
> }}
> {code}
> As can be seen, the document with id:2 now contains the child with id:11 that
> belongs to the document with id:1.
> I haven't found any references on the web about this except
> http://blog.griddynamics.com/2013/09/solr-block-j
[jira] [Commented] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14202006#comment-14202006
]
Bogdan Marinescu commented on SOLR-6700:
I have some follow-up questions:
1. Can you tell me what exactly the optimiser is doing ? Because everything
works well until I call optimise. Afterwards, the ChildDocTransformer returns
the wrong children, including other "parents".
I've seen that it reduces the segment count (default to 1), and that the
"Deleted Docs" are back to 0. Is it really worth it ? Can not using the
optimiser lead to performance problems?
2. Is there any other possibility other than ChildDocTransformer to get the
children documents for a parent ? (expand query?) How exactly does the [child]
transformer work ? Apparently it's not using the _root_ field, because if it
were using it, it would group the parent-children correctly.
Thanks
> ChildDocTransformer doesn't return correct children after updating and
> optimising sol'r index
> -
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"},
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]},
> {
> "id":"1",
> "pName":"INIT",
> "entityType":1,
> "_root_":"1",
> "_version_":1483832916867809280,
> "score":1.0}]
> }}
> {code}
> As can be seen, the document with id:2 now contains the child with id:11 that
> belongs to the document with id:1.
> I haven't found any references on the web about this except
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html
> Similar issue: SOLR-6
[jira] [Comment Edited] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199964#comment-14199964
]
Bogdan Marinescu edited comment on SOLR-6700 at 11/6/14 7:52 AM:
-
That's exactly what I've been doing.
{code:title=update_parent.xml|borderStyle=solid}
1
INIT
1
11
Test Album 1
Test Song 1
2
{code}
This yields the same result. If instead I use this but without the
'update="set"' part, it replaces the parent and everything works, and best of
all, no optimisation is required, probably because the index is not fragmented.
{code}
1
INIT
1
11
Test Album 1
Test Song 1
2
{code}
Question remains though, why doesn't it work with the update="set" flag ? The
problem with replacing the document is that instead of just setting the
field/fields to be updated, you have to submit the whole document and their
children.
As I've said before, the data gets "scrambled" only after the *optimise* is
performed.
Am I to understand that this bug won't be solved anytime soon ?
was (Author: bogandy):
That's exactly what I've been doing.
{code:title=update_parent.xml|borderStyle=solid}
1
INIT
1
11
Test Album 1
Test Song 1
2
{code}
This yields the same result. If instead I use this but without the
'update="set"' part, it replaces the parent and everything works, and best of
all, no optimisation is required, probably because the index is not fragmented.
Question remains though, why doesn't it work with the update="set" flag ? The
problem with replacing the document is that instead of just setting the
field/fields to be updated, you have to submit the whole document and their
children.
As I've said before, the data gets "scrambled" only after the *optimise* is
performed.
Am I to understand that this bug won't be solved anytime soon ?
> ChildDocTransformer doesn't return correct children after updating and
> optimising sol'r index
> -
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "respons
[jira] [Commented] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199964#comment-14199964
]
Bogdan Marinescu commented on SOLR-6700:
That's exactly what I've been doing.
{code:title=update_parent.xml|borderStyle=solid}
1
INIT
1
11
Test Album 1
Test Song 1
2
{code}
This yields the same result. If instead I use this but without the
'update="set"' part, it replaces the parent and everything works, and best of
all, no optimisation is required, probably because the index is not fragmented.
Question remains though, why doesn't it work with the update="set" flag ? The
problem with replacing the document is that instead of just setting the
field/fields to be updated, you have to submit the whole document and their
children.
As I've said before, the data gets "scrambled" only after the *optimise* is
performed.
Am I to understand that this bug won't be solved anytime soon ?
> ChildDocTransformer doesn't return correct children after updating and
> optimising sol'r index
> -
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"},
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]},
> {
> "id":"1",
> "pName":"INIT",
> "entityType":1,
> "_root_":"1",
> "_version_":1483832916867809280,
> "score":1.0}]
> }}
> {code}
> As can be seen, the document with id:2 now contains the child with id:11 that
> belongs to the document with id:1.
> I haven't found any references on the web about this except
> http://blog.grid
[jira] [Commented] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197809#comment-14197809
]
Bogdan Marinescu commented on SOLR-6700:
How do I reindex whole block ? (eventually with solrj?)
> ChildDocTransformer doesn't return correct children after updating and
> optimising sol'r index
> -
>
> Key: SOLR-6700
> URL: https://issues.apache.org/jira/browse/SOLR-6700
> Project: Solr
> Issue Type: Bug
>Reporter: Bogdan Marinescu
>Priority: Blocker
> Fix For: 4.10.3, 5.0
>
>
> I have an index with nested documents.
> {code:title=schema.xml snippet|borderStyle=solid}
> multiValued="false" />
> required="true"/>
>
>
>
>
>
> {code}
> Afterwards I add the following documents:
> {code}
>
>
> 1
> Test Artist 1
> 1
>
> 11
> Test Album 1
> Test Song 1
> 2
>
>
>
> 2
> Test Artist 2
> 1
>
> 22
> Test Album 2
> Test Song 2
> 2
>
>
>
> {code}
> After performing the following query
> {quote}
> http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
> {quote}
> I get a correct answer (child matches parent, check _root_ field)
> {code:title=add docs|borderStyle=solid}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"1",
> "pName":"Test Artist 1",
> "entityType":1,
> "_version_":1483832661048819712,
> "_root_":"1",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"}]},
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]}]
> }}
> {code}
> Afterwards I try to update one document:
> {code:title=update doc|borderStyle=solid}
>
>
> 1
> INIT
>
>
> {code}
> After performing the previous query I get the right result (like the previous
> one but with the pName field updated).
> The problem only comes after performing an *optimize*.
> Now, the same query yields the following result:
> {code}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "fl":"*,score,[child parentFilter=entityType:1]",
> "indent":"true",
> "q":"{!parent which=entityType:1}",
> "wt":"json"}},
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
> {
> "id":"2",
> "pName":"Test Artist 2",
> "entityType":1,
> "_version_":1483832661050916864,
> "_root_":"2",
> "score":1.0,
> "_childDocuments_":[
> {
> "id":"11",
> "cAlbum":"Test Album 1",
> "cSong":"Test Song 1",
> "entityType":2,
> "_root_":"1"},
> {
> "id":"22",
> "cAlbum":"Test Album 2",
> "cSong":"Test Song 2",
> "entityType":2,
> "_root_":"2"}]},
> {
> "id":"1",
> "pName":"INIT",
> "entityType":1,
> "_root_":"1",
> "_version_":1483832916867809280,
> "score":1.0}]
> }}
> {code}
> As can be seen, the document with id:2 now contains the child with id:11 that
> belongs to the document with id:1.
> I haven't found any references on the web about this except
> http://blog.griddynamics.com/2013/09/solr-block-join-support.html
> Similar issue: SOLR-6096
> Is this problem known? Is there a workaround for this?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Marinescu updated SOLR-6700:
---
Description:
I have an index with nested documents.
{code:title=schema.xml snippet|borderStyle=solid}
{code}
Afterwards I add the following documents:
{code}
1
Test Artist 1
1
11
Test Album 1
Test Song 1
2
2
Test Artist 2
1
22
Test Album 2
Test Song 2
2
{code}
After performing the following query
{quote}
http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
{quote}
I get a correct answer (child matches parent, check _root_ field)
{code:title=add docs|borderStyle=solid}
{
"responseHeader":{
"status":0,
"QTime":1,
"params":{
"fl":"*,score,[child parentFilter=entityType:1]",
"indent":"true",
"q":"{!parent which=entityType:1}",
"wt":"json"}},
"response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
{
"id":"1",
"pName":"Test Artist 1",
"entityType":1,
"_version_":1483832661048819712,
"_root_":"1",
"score":1.0,
"_childDocuments_":[
{
"id":"11",
"cAlbum":"Test Album 1",
"cSong":"Test Song 1",
"entityType":2,
"_root_":"1"}]},
{
"id":"2",
"pName":"Test Artist 2",
"entityType":1,
"_version_":1483832661050916864,
"_root_":"2",
"score":1.0,
"_childDocuments_":[
{
"id":"22",
"cAlbum":"Test Album 2",
"cSong":"Test Song 2",
"entityType":2,
"_root_":"2"}]}]
}}
{code}
Afterwards I try to update one document:
{code:title=update doc|borderStyle=solid}
1
INIT
{code}
After performing the previous query I get the right result (like the previous
one but with the pName field updated).
The problem only comes after performing an *optimize*.
Now, the same query yields the following result:
{code}
{
"responseHeader":{
"status":0,
"QTime":1,
"params":{
"fl":"*,score,[child parentFilter=entityType:1]",
"indent":"true",
"q":"{!parent which=entityType:1}",
"wt":"json"}},
"response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
{
"id":"2",
"pName":"Test Artist 2",
"entityType":1,
"_version_":1483832661050916864,
"_root_":"2",
"score":1.0,
"_childDocuments_":[
{
"id":"11",
"cAlbum":"Test Album 1",
"cSong":"Test Song 1",
"entityType":2,
"_root_":"1"},
{
"id":"22",
"cAlbum":"Test Album 2",
"cSong":"Test Song 2",
"entityType":2,
"_root_":"2"}]},
{
"id":"1",
"pName":"INIT",
"entityType":1,
"_root_":"1",
"_version_":1483832916867809280,
"score":1.0}]
}}
{code}
As can be seen, the document with id:2 now contains the child with id:11 that
belongs to the document with id:1.
I haven't found any references on the web about this except
http://blog.griddynamics.com/2013/09/solr-block-join-support.html
Similar issue: SOLR-6096
Is this problem known? Is there a workaround for this?
was:
I have an index with nested documents.
{code:title=schema.xml snippet|borderStyle=solid}
{code}
Afterwards I add the following documents:
{code}
1
Test Artist 1
1
11
Test Album 1
Test Song 1
2
2
Test Artist 2
1
22
Test Album 2
Test Song 2
2
{code}
After performing the following query
{quote}
http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
{quote}
I get a correct answer (child matches parent, check _root_ field)
{code:title=add docs|borderStyle=solid}
{
"responseHeader":{
"status":0,
"QTime":1,
"params":{
"fl":"*,score,[child parentFilter=entityType:1]",
"indent":"true",
"q":"{!parent which=entityType:1}",
"wt":"json"}},
"response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
{
"id":"1",
"pName":"Test Artist 1",
"entityType":1,
"_version_":1483832661048819712,
"_root_":"1",
"score":1.0,
"_childDocuments_":[
{
"id":"11",
"cAlbum":"Test Album 1",
"cSong":"Test Song 1",
"entityType":2,
"_root_":"1"}]},
{
"id":"2",
"pName":"Test Artist 2",
"entityType":1,
"_version_":1483832661050916864,
"_root_":"2",
[jira] [Updated] (SOLR-6700) ChildDocTransformer doesn't return correct children after updating and optimising sol'r index
[
https://issues.apache.org/jira/browse/SOLR-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Marinescu updated SOLR-6700:
---
Description:
I have an index with nested documents.
{code:title=schema.xml snippet|borderStyle=solid}
{code}
Afterwards I add the following documents:
{code}
1
Test Artist 1
1
11
Test Album 1
Test Song 1
2
2
Test Artist 2
1
22
Test Album 2
Test Song 2
2
{code}
After performing the following query
{quote}
http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
{quote}
I get a correct answer (child matches parent, check _root_ field)
{code:title=add docs|borderStyle=solid}
{
"responseHeader":{
"status":0,
"QTime":1,
"params":{
"fl":"*,score,[child parentFilter=entityType:1]",
"indent":"true",
"q":"{!parent which=entityType:1}",
"wt":"json"}},
"response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
{
"id":"1",
"pName":"Test Artist 1",
"entityType":1,
"_version_":1483832661048819712,
"_root_":"1",
"score":1.0,
"_childDocuments_":[
{
"id":"11",
"cAlbum":"Test Album 1",
"cSong":"Test Song 1",
"entityType":2,
"_root_":"1"}]},
{
"id":"2",
"pName":"Test Artist 2",
"entityType":1,
"_version_":1483832661050916864,
"_root_":"2",
"score":1.0,
"_childDocuments_":[
{
"id":"22",
"cAlbum":"Test Album 2",
"cSong":"Test Song 2",
"entityType":2,
"_root_":"2"}]}]
}}
{code}
Afterwards I try to update one document:
{code:title=update doc|borderStyle=solid}
1
INIT
{code}
After performing the previous query I get the right result (like the previous
one but with the pName field updated).
The problem only comes after performing an *optimize*.
Now, the same query yields the following result:
{code}
{
"responseHeader":{
"status":0,
"QTime":1,
"params":{
"fl":"*,score,[child parentFilter=entityType:1]",
"indent":"true",
"q":"{!parent which=entityType:1}",
"wt":"json"}},
"response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
{
"id":"2",
"pName":"Test Artist 2",
"entityType":1,
"_version_":1483832661050916864,
"_root_":"2",
"score":1.0,
"_childDocuments_":[
{
"id":"11",
"cAlbum":"Test Album 1",
"cSong":"Test Song 1",
"entityType":2,
"_root_":"1"},
{
"id":"22",
"cAlbum":"Test Album 2",
"cSong":"Test Song 2",
"entityType":2,
"_root_":"2"}]},
{
"id":"1",
"pName":"INIT",
"entityType":1,
"_root_":"1",
"_version_":1483832916867809280,
"score":1.0}]
}}
{code}
As can be seen, the document with id:2 now contains the child with id:11 that
belongs to the document with id:1.
I haven't found any references on the web about this except
http://blog.griddynamics.com/2013/09/solr-block-join-support.html
Is this problem known? Is there a workaround for this?
was:
I have an index with nested documents.
{code:title=schema.xml snippet|borderStyle=solid}
{code}
Afterwards I add the following documents:
{code}
1
Test Artist 1
1
11
Test Album 1
Test Song 1
2
2
Test Artist 2
1
22
Test Album 2
Test Song 2
2
{code}
After performing the following query
{quote}
http://localhost:8983/solr/collection1/select?q=%7B!parent+which%3DentityType%3A1%7D&fl=*%2Cscore%2C%5Bchild+parentFilter%3DentityType%3A1%5D&wt=json&indent=true
{quote}
I get a correct answer (child matches parent, check _root_ field)
{code:title=add docs|borderStyle=solid}
{
"responseHeader":{
"status":0,
"QTime":1,
"params":{
"fl":"*,score,[child parentFilter=entityType:1]",
"indent":"true",
"q":"{!parent which=entityType:1}",
"wt":"json"}},
"response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
{
"id":"1",
"pName":"Test Artist 1",
"entityType":1,
"_version_":1483832661048819712,
"_root_":"1",
"score":1.0,
"_childDocuments_":[
{
"id":"11",
"cAlbum":"Test Album 1",
"cSong":"Test Song 1",
"entityType":2,
"_root_":"1"}]},
{
"id":"2",
"pName":"Test Artist 2",
"entityType":1,
"_version_":1483832661050916864,
"_root_":"2",
"score":1.0,
