Good to hear. Joel Bernstein http://joelsolr.blogspot.com/
On Sun, Jul 21, 2019 at 5:21 PM Ahmed Adel <aa...@delyvery.ai> wrote: > Yeah, it turned out to be related to the data. The “fetch” method works > fine as you described, it’s just the data distribution that caused name > field not to be fetched in a number of responses. I tested it with two > other collections and it worked as expected as well. Thank you for your > help getting this running. > > Best, > A. Adel > > On Sun, Jul 21, 2019 at 2:36 AM Joel Bernstein <joels...@gmail.com> wrote: > > > Ok, then it sounds like a different issue. Let's look at the logs > following > > a request and see what the issue is. There will be a log record that > shows > > the query that is sent to Solr by the fetch expression. When we look at > > that log we'll be able to see what the query is, and if results are > > returned. It could be a bug in the code or it could be something related > to > > the data that's being fetched. > > > > > > Joel Bernstein > > http://joelsolr.blogspot.com/ > > > > > > On Sat, Jul 20, 2019 at 5:21 PM Ahmed Adel <aa.0...@gmail.com> wrote: > > > > > To validate this, I indexed the datasets and ran the same query on Solr > > > 6.5.0 environment (https://archive.apache.org/dist/lucene/solr/6.5.0/) > > > before cb9f15 commit gets into release but got the same response, no > > > additional fields, as Solr 8.1.1. I have used the default managed > schema > > > settings in both Solr versions, which I guess means qparser is not used > > for > > > /select in this case, is it? > > > > > > On Sat, Jul 20, 2019 at 2:02 AM Joel Bernstein <joels...@gmail.com> > > wrote: > > > > > > > I suspect fetch is having problem due to this commit: > > > > > > > > > > > > > > > > > > https://github.com/apache/lucene-solr/commit/cb9f151db4b5ad5c5f581b6b8cf2e5916ddb0f35#diff-98abfc8855d347035205c6f3afc2cde3 > > > > > > > > Later local params were turned off for anything but the lucene > qparser. > > > > Which means this query doesn't work if /select is using edismax > etc... > > > > > > > > This needs to be fixed. > > > > Can you check to see if the qparser is for the /select handler on > your > > > > install? > > > > > > > > Anyway fetch needs to be reverted back to it's previous > implementation > > > > before the above commit basically broke it. > > > > > > > > > > > > > > > > > > > > Joel Bernstein > > > > http://joelsolr.blogspot.com/ > > > > > > > > > > > > On Fri, Jul 19, 2019 at 2:20 PM Ahmed Adel <aa.0...@gmail.com> > wrote: > > > > > > > > > Hi - Tried swapping the equality sides but (surprisingly?) got the > > same > > > > > exact response. Any additional thoughts are appreciated. > > > > > > > > > > Best, > > > > > A. > > > > > http://aadel.io > > > > > > > > > > On Fri, Jul 19, 2019 at 5:27 PM Joel Bernstein <joels...@gmail.com > > > > > > wrote: > > > > > > > > > > > Try: > > > > > > > > > > > > fetch(names, > > > > > > select( > > > > > > nodes(emails, > > > > > > walk="john...@apache.org->from", > > > > > > gather="to"), > > > > > > node as to_s), > > > > > > fl="name", > > > > > > on="to_s=email") > > > > > > > > > > > > > > > > > > According to the docs it looks like you have the fields reversed > on > > > the > > > > > > fetch. If that doesn't work, I'll investigate further. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Joel Bernstein > > > > > > http://joelsolr.blogspot.com/ > > > > > > > > > > > > > > > > > > On Fri, Jul 19, 2019 at 5:51 AM Ahmed Adel <aa.0...@gmail.com> > > > wrote: > > > > > > > > > > > > > Hi Joel, > > > > > > > > > > > > > > Thank you for your thoughts. I tried the fetch function, > however, > > > the > > > > > > > response does not contain "fl" fields of the "fetch" > expression. > > > For > > > > > the > > > > > > > above example, the modified query is as follows: > > > > > > > > > > > > > > fetch(names, select(nodes(emails, > > > > > > > walk="john...@apache.org->from", > > > > > > > gather="to"), node as to_s), fl="name", on="email=to_s") > > > > > > > > > > > > > > > > > > > > > where "names" is a collection that contains two fields > > representing > > > > > pairs > > > > > > > of name and email: ("name", "email") > > > > > > > > > > > > > > The response returned is: > > > > > > > > > > > > > > { "result-set": { "docs": [ { "to_s": "john...@apache.org" > > > > > > > }, { "to_s": "johnsm...@apache.org" > > > > > > > }, > > > > > > > ... { "EOF": true, "RESPONSE_TIME": 33 } ] } } > > > > > > > > > > > > > > The response should have an additional "name" field in each > > > document > > > > > > > returned. Any additional thoughts are appreciated. > > > > > > > > > > > > > > Best, > > > > > > > A. > > > > > > > > > > > > > > On Thu, Jul 18, 2019 at 6:12 PM Joel Bernstein < > > joels...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Ahmed, > > > > > > > > > > > > > > > > Take a look at the fetch > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lucene.apache.org/solr/guide/8_0/stream-decorator-reference.html#fetch > > > > > > > > > > > > > > > > It probably makes sense to allow more field to be returned > > from a > > > > > nodes > > > > > > > > expression as well. > > > > > > > > > > > > > > > > Joel Bernstein > > > > > > > > http://joelsolr.blogspot.com/ > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 17, 2019 at 3:12 AM Ahmed Adel < > aa.0...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Thank you for your reply. Could you give more details on > the > > > > „join“ > > > > > > > > > operation, such as what the sides of the join and the > joining > > > > > > condition > > > > > > > > > would be in this case? > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > A. > > > > > > > > > > > > > > > > > > On Tue, Jul 16, 2019 at 2:02 PM markus kalkbrenner < > > > > > > > > > markus.kalkbren...@biologis.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You have to perform a „join“ to get more fields. > > > > > > > > > > > > > > > > > > > > > Am 16.07.2019 um 13:52 schrieb Ahmed Adel < > > > aa.0...@gmail.com > > > > >: > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > How can multiple fields be returned in graph traversal > > > > > streaming > > > > > > > > > > expression > > > > > > > > > > > response documents? For example, the following query: > > > > > > > > > > > > > > > > > > > > > > nodes(emails, > > > > > > > > > > > walk="john...@apache.org->from", > > > > > > > > > > > gather="to") > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > returns these documents in the response: > > > > > > > > > > > > > > > > > > > > > > { > > > > > > > > > > > "result-set": { > > > > > > > > > > > "docs": [ > > > > > > > > > > > { > > > > > > > > > > > "node": "sl...@campbell.com", > > > > > > > > > > > "collection": "emails", > > > > > > > > > > > "field": "to", > > > > > > > > > > > "level": 1 > > > > > > > > > > > }, > > > > > > > > > > > { > > > > > > > > > > > "node": "catherine.per...@enron.com", > > > > > > > > > > > "collection": "emails", > > > > > > > > > > > "field": "to", > > > > > > > > > > > "level": 1 > > > > > > > > > > > }, > > > > > > > > > > > { > > > > > > > > > > > "node": "airam.arte...@enron.com", > > > > > > > > > > > "collection": "emails", > > > > > > > > > > > "field": "to", > > > > > > > > > > > "level": 1 > > > > > > > > > > > }, > > > > > > > > > > > { > > > > > > > > > > > "EOF": true, > > > > > > > > > > > "RESPONSE_TIME": 44 > > > > > > > > > > > } > > > > > > > > > > > ] > > > > > > > > > > > } > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > How can the query above be modified to return more > > document > > > > > > fields, > > > > > > > > > > > "subject" for example? > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > > > A. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sent from my iPhone > > > > > > > > > > > > > > > -- > Ahmed Adel > VP of Engineering > delyvery.ai >
