Hi Chris: Thanks a lot for your response. This is the kind of information I'm looking for.
What you said about faceting is the key. I want to use my existing edismax configuration to create the scored document result set of type Y. I don't want to affect their scores, but for each document ID, I want join it with another type of document (X), which has a field which contains a document ID of one of Y. There will be zero or more of these per Y doc ID. The X document then has a multi-valued field I would like to facet. I don't need scores for the joined X documents. This does not sound possible according to the end of your final paragraph. Is that because two cores are involved? Despite the join syntax, I don't see any way to specify a facet.field parameter which indicates both a core and a field name. What if a single core is used (no fromIndex), containing both the X and Y type documents? They will all have unique IDs, and I could I specify facet.field=y_abc&facet.field=x_abc? I know Solr is all about denormalization, but I don't want to have to add frequently changing fields (X) to my very infrequently updated canonical content (Y) just to be able to facet on them. Thanks! Jeff On Dec 5, 2011, at 5:11 PM, Chris Hostetter wrote: > Jeff, > > I'm not entirely understanding everything you've been asking about (in > terms of what your ultimate goal is) but as far as the JoinQParser > specificially... > > > : > http://localhost:8091/solr/ing-content/select/?qt=partner-tmo&fq=type:node&q={!join+from=conceptId+to=id+fromIndex=partner-tmo}brca1&debugQuery=true&rows=5&fl=id,n_type,n_name > ... > : <str name="parsedquery_toString">{!join from=conceptId to=id > fromIndex=partner-tmo}n_text:brca</str> > ... > : It looks like despite qt=partner-tmo, the edismax based search hander is > : being bypassed for the default search handler, and is querying against > : the n_text field, which is the defaultSearchField for the ing-conent > : core. But, I don't want to use the default handler, but rather my > : configured edismax hander, and any specified filter queries, to > : determine the document set in the ing-conent core, and then join with > : the partner-tmo core. [Yes, the edismax handler in the ing-content core > : and the second core are both named partner-tmo]. > > ...i *think* what you are getting bitten by here is SOLR-2824 - a bug in > the JoinQParser relating to how it parses the query that it should be > executing against the "fromIndex". At the moment it is *parsed* according > to the configs of the index you are quering against, and then that query > is *executed* against the SolrCore identified by the "fromIndex" param ... > i'm not sure if knowing that will help you work arround this bug until it > gets fixed ,but it might help if you can tweak your configs/request to > make the query "make sense" in your "ing-content" collection. > > In general though, i'm not certain that what you are trying to do will be > solvable with Join, based on some of your earlier comments -- the main > thing to remember is that {!join} is just a QParser that only matches some > document Y if Y's "to" field "joins up" against some other document X's > "from" field and document X matches the query the {!join} wraps. It > doesn't give you any of the scores from the joined X documents, or cause > any of the fields from X to be useable when faceting on Y. (Just putting > all that out there so you know in case those are deal breakers that are > going to force you to re-think your approach) > > > -Hoss -- Jeff Schmidt 535 Consulting j...@535consulting.com http://www.535consulting.com (650) 423-1068
