[jira] [Commented] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15215950#comment-15215950
]
Tom Winch commented on SOLR-7341:
-
Thanks for your input, Erick! My feeling is that this JIRA would work
independently to SA. I don't think it is incompatible at all. However I don't
think it would be right to use XJoin for Solr/Solr, that feels like hammer to
crack a nut.
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.2, master
>
> Attachments: SOLR-7341.patch-4.10.3, SOLR-7341.patch-4_10,
> SOLR-7341.patch-5.3.2, SOLR-7341.patch-5_3, SOLR-7341.patch-master,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source (but
> see below for details of how to use the in-built SimpleXJoinResultsFactory
> implementation). External results and SOLR documents are matched via a single
> configurable attribute (the "join field").
> To include the XJoin contrib classes, add the following config to
> solrconfig.xml:
> {code:xml}
>
> ..
>
>regex=".*\.jar" />
>regex="solr-xjoin-\d.*\.jar" />
> ..
>
> {code}
> Note that any JARs containing implementations of the XJoinResultsFactory must
> also be included.
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end
[jira] [Commented] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15208424#comment-15208424
]
Tom Winch commented on SOLR-7341:
-
XJoin isn't like the joins on SOLR-7090 because it joins against an external
data source rather than a SOLR core. In addition it decorates the standard SOLR
results which is rather different to how I understand SA would behave.
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.2, master
>
> Attachments: SOLR-7341.patch-4.10.3, SOLR-7341.patch-4_10,
> SOLR-7341.patch-5.3.2, SOLR-7341.patch-5_3, SOLR-7341.patch-master,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source (but
> see below for details of how to use the in-built SimpleXJoinResultsFactory
> implementation). External results and SOLR documents are matched via a single
> configurable attribute (the "join field").
> To include the XJoin contrib classes, add the following config to
> solrconfig.xml:
> {code:xml}
>
> ..
>
>regex=".*\.jar" />
>regex="solr-xjoin-\d.*\.jar" />
> ..
>
> {code}
> Note that any JARs containing implementations of the XJoinResultsFactory must
> also be included.
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Fix Version/s: (was: 5.3.1)
5.3.2
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.2, master
>
> Attachments: SOLR-7341.patch-4.10.3, SOLR-7341.patch-4_10,
> SOLR-7341.patch-5.3.2, SOLR-7341.patch-5_3, SOLR-7341.patch-master,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source (but
> see below for details of how to use the in-built SimpleXJoinResultsFactory
> implementation). External results and SOLR documents are matched via a single
> configurable attribute (the "join field").
> To include the XJoin contrib classes, add the following config to
> solrconfig.xml:
> {code:xml}
>
> ..
>
>regex=".*\.jar" />
>regex="solr-xjoin-\d.*\.jar" />
> ..
>
> {code}
> Note that any JARs containing implementations of the XJoinResultsFactory must
> also be included.
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch-master
SOLR-7341.patch-5.3.2
SOLR-7341.patch-4.10.3
Git patches for 4.10.3, 5.3.2 and master that include the
SimpleXJoinResultsFactory
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.1, master
>
> Attachments: SOLR-7341.patch-4.10.3, SOLR-7341.patch-4_10,
> SOLR-7341.patch-5.3.2, SOLR-7341.patch-5_3, SOLR-7341.patch-master,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source (but
> see below for details of how to use the in-built SimpleXJoinResultsFactory
> implementation). External results and SOLR documents are matched via a single
> configurable attribute (the "join field").
> To include the XJoin contrib classes, add the following config to
> solrconfig.xml:
> {code:xml}
>
> ..
>
>regex=".*\.jar" />
>regex="solr-xjoin-\d.*\.jar" />
> ..
>
> {code}
> Note that any JARs containing implementations of the XJoinResultsFactory must
> also be included.
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Description:
h2. XJoin
The "xjoin" SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent,
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory
and XJoinResults, which are implemented by the user to provide the link between
SOLR and the external results source (but see below for details of how to use
the in-built SimpleXJoinResultsFactory implementation). External results and
SOLR documents are matched via a single configurable attribute (the "join
field").
To include the XJoin contrib classes, add the following config to
solrconfig.xml:
{code:xml}
..
..
{code}
Note that any JARs containing implementations of the XJoinResultsFactory must
also be included.
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix ".external." are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, .external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* Iterable getJoinIds() - this should return an ordered (ascending)
list of the join attribute values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
There is one XJoin search component per external source, and each has two main
responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
test.TestXJoinResultsFactory
id
1,2,3
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the "values" parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
..
true
xx
test_count
id,value
xjoin_test
xjoin_test
{code}
Note that, to include the list of join ids returned by the external source in
the SOLR results (likely for debug purposes), the value 'join_ids' may be
specified in the "results" parameter.
h3. XJoinQParserPlugin
This query parser plugin constructs a query from the results of the external
searches, and is based on the TermsQParserPlugin. It takes the following local
parameters:
* method - as the TermsQParserPlugin, this specifies how to build the Lucene
query based on the join ids contained in external results; one of termsFilter,
booleanQuery, automaton,
[jira] [Commented] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167034#comment-15167034
]
Tom Winch commented on SOLR-8234:
-
That would be another approach, I guess. You'd still have to write the
(custom) merge code, and the approach of this JIRA means you get back SOLR
results as per usual, and it's a plugin that makes use of the existing
distributed search mechanisms for requesting the top N unique ids from each
server and merge-ranking them etc.
> Federated Search (new) - DJoin
> --
>
> Key: SOLR-8234
> URL: https://issues.apache.org/jira/browse/SOLR-8234
> Project: Solr
> Issue Type: New Feature
>Reporter: Tom Winch
>Priority: Minor
> Labels: federated_search
> Fix For: 4.10.3
>
> Attachments: SOLR-8234.patch, SOLR-8234.patch, SOLR-8234.patch
>
>
> This issue describes a MergeStrategy implementation (DJoin) to facilitate
> federated search - that is, distributed search over documents stored in
> separated instances of SOLR (for example, one server per continent), where a
> single document (identified by an agreed, common unique id) may be stored in
> more than one server instance, with (possibly) differing fields and data.
> When the MergeStrategy is used in a request handler (via the included
> QParser) in combination with distributed search (shards=), documents having
> an id that has already been seen are not discarded (as per the default
> behaviour) but, instead, are collected and returned as a group of documents
> all with the same id taking a single position in the result set (this is
> implemented using parent/child documents, with an indicator field in the
> parent - see example output, below).
> Documents are sorted in the result set based on the highest ranking document
> with the same id. It is possible for a document ranking high in one shard to
> rank very low on another shard. As a consequence of this, all shards must be
> asked to return the fields for every document id in the result set (not just
> of those documents they returned), so that all the component parts of each
> document in the search result set are returned.
> As usual, search parameters are passed on to each shard. So that the shards
> do not need any additional configurations in their definition of the /select
> request handler, we use the FilterQParserSearchComponent which is configured
> to filter out the \{!djoin\} search parameter - otherwise, the target request
> handler complains about the missing query parser definition. See the example
> config, below.
> This issue combines with others to provide full federated search support. See
> also SOLR-8235 and SOLR-8236.
> Note that this is part of a new implementation of federated search as opposed
> to the older issues SOLR-3799 through SOLR-3805.
> --
> Example request handler configuration:
> {code:xml}
>class="org.apache.solr.search.federated.FilterDJoinQParserSearchComponent" />
>
>class="org.apache.solr.search.federated.DJoinQParserPlugin" />
>
>
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> {!djoin}
>
>
> filter
>
>
> {code}
> Example output:
> {code:xml}
>
>
>
> 0
> 33
>
> *:*
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> xml
> {!djoin}
> *,[shard]
>
>
>
>
> true
>
> 200
> 1973
> http://shard2/solr/core
> 1515645309629235200
>
>
> 200
> 2015
> http://shard1/solr/core
> 1515645309682712576
>
>
>
> true
>
> 100
> 873
> http://shard1/solr/core
> 1515645309629254124
>
>
> 100
> 2001
> http://shard3/solr/core
> 1515645309682792852
>
>
>
> true
>
> 300
> 1492
> http://shard2/solr/core
> 1515645309629251252
>
>
>
>
> {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...@lucene.apache.org
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch-trunk
git patch
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.1, Trunk
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-5_3,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be
[jira] [Comment Edited] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138902#comment-15138902
]
Tom Winch edited comment on SOLR-7341 at 2/9/16 1:00 PM:
-
trunk patch is for git; others (remain) for svn
was (Author: tomjon):
git patch
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.1, Trunk
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-5_3,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Affects Version/s: (was: 4.10.3)
Fix Version/s: 4.10.3
5.3.1
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Tom Winch
>Priority: Minor
> Fix For: 4.10.3, 5.3.1, Trunk
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-5_3,
> SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch-5_3
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-5_3, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
> {code:xml}
>
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch-5_3, SOLR-7341.patch-trunk,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch-5_3, SOLR-7341.patch-trunk,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch-5_3)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
> {code:xml}
>
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
> {code:xml}
>
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch-trunk)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
> {code:xml}
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch-trunk)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
> {code:xml}
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
> {code:xml}
>
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
> {code:xml}
>
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Description:
h2. XJoin
The "xjoin" SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent,
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory
and XJoinResults, which are implemented by the user to provide the link between
SOLR and the external results source. External results and SOLR documents are
matched via a single configurable attribute (the "join field"). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
..
..
..
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix ".external." are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, .external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* Iterable getJoinIds() - this should return an ordered (ascending)
list of the join attribute values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
There is one XJoin search component per external source, and each has two main
responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
test.TestXJoinResultsFactory
id
1,2,3
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the "values" parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
..
true
xx
test_count
id,value
xjoin_test
xjoin_test
{code}
Note that, to include the list of join ids returned by the external source in
the SOLR results (likely for debug purposes), the value 'join_ids' may be
specified in the "results" parameter.
h3. XJoinQParserPlugin
This query parser plugin constructs a query from the results of the external
searches, and is based on the TermsQParserPlugin. It takes the following local
parameters:
* method - as the TermsQParserPlugin, this specifies how to build the Lucene
query based on the join ids contained in external results; one of termsFilter,
booleanQuery, automaton, or
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch-5_3)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
> {code:xml}
>
>
> ..
> true
> xx
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch-trunk)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in the SOLR results
> For example:
> {code:xml}
>
>
> ..
> true
> xx
>
[jira] [Issue Comment Deleted] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Comment: was deleted
(was: Working version!)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-5_3,
> SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects (contained
> in an XJoinResults implementation) to be included in
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch-trunk
SOLR-7341.patch-5_3
SOLR-7341.patch-4_10
New patches with slightly improved output format
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch-4_10, SOLR-7341.patch-5_3,
> SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch-5_3)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-trunk,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch-5_3
Working version!
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-5_3,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
>
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch-5_3
Patch for SOLR 5.3
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-5_3,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
[jira] [Commented] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062077#comment-15062077
]
Tom Winch commented on SOLR-7341:
-
Done
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-5_3,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl -
[jira] [Updated] (SOLR-8235) Federated Search (new) - Merge
[ https://issues.apache.org/jira/browse/SOLR-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8235: Attachment: (was: SOLR-8235.patch) > Federated Search (new) - Merge > -- > > Key: SOLR-8235 > URL: https://issues.apache.org/jira/browse/SOLR-8235 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > Attachments: SOLR-8235.patch > > > This issue describes a SearchComponent for merging search results obtained > from a DJoin distributed search (see SOLR-8234) as part of federated search - > that is, distributed search over documents stored in separated instances of > SOLR (for example, one server per continent), where a single document > (identified by an agreed, common unique id) may be stored in more than one > server instance, with (possibly) differing fields and data. > In the use of this search component, it is assumed that there is a single > SOLR server (the "aggregator") that uses distributed search (shards=) to > collect documents from other SOLR servers using DJoin (see SOLR-8234). The > DJoin generates a result set containing parent documents each with child > documents having the same unique id. This merge component turns each set of > child documents into a single document conforming to the aggregator schema. > For example, suppose the aggregator schema defines a multi-valued integer > field, 'num', and three shards return field values "48", 23, and > "strawberry". Then the resulting merged field value would be [48, 23] and an > error would included for the NumberFormatException. > Custom field merge behaviour may be specified by defining custom field types > in the usual way and this is supported via a MergeAbstractFieldType class. > This issue combines with others to provide full federated search support. See > also SOLR-8234 and SOLR-8236. > – > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- 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-8235) Federated Search (new) - Merge
[ https://issues.apache.org/jira/browse/SOLR-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8235: Attachment: SOLR-8235.patch patch against SOLR 4.10.3 > Federated Search (new) - Merge > -- > > Key: SOLR-8235 > URL: https://issues.apache.org/jira/browse/SOLR-8235 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > Attachments: SOLR-8235.patch > > > This issue describes a SearchComponent for merging search results obtained > from a DJoin distributed search (see SOLR-8234) as part of federated search - > that is, distributed search over documents stored in separated instances of > SOLR (for example, one server per continent), where a single document > (identified by an agreed, common unique id) may be stored in more than one > server instance, with (possibly) differing fields and data. > In the use of this search component, it is assumed that there is a single > SOLR server (the "aggregator") that uses distributed search (shards=) to > collect documents from other SOLR servers using DJoin (see SOLR-8234). The > DJoin generates a result set containing parent documents each with child > documents having the same unique id. This merge component turns each set of > child documents into a single document conforming to the aggregator schema. > For example, suppose the aggregator schema defines a multi-valued integer > field, 'num', and three shards return field values "48", 23, and > "strawberry". Then the resulting merged field value would be [48, 23] and an > error would included for the NumberFormatException. > Custom field merge behaviour may be specified by defining custom field types > in the usual way and this is supported via a MergeAbstractFieldType class. > This issue combines with others to provide full federated search support. See > also SOLR-8234 and SOLR-8236. > – > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- 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-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15050620#comment-15050620
]
Tom Winch commented on SOLR-7341:
-
I can do - I presume you tried applying the trunk patch and it didn't work?
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-trunk,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search
[jira] [Commented] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15050619#comment-15050619
]
Tom Winch commented on SOLR-7341:
-
I can do - I presume you tried applying the trunk patch and it didn't work?
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-trunk,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search
[jira] [Issue Comment Deleted] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Comment: was deleted
(was: I can do - I presume you tried applying the trunk patch and it didn't
work?)
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-trunk,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to
[jira] [Issue Comment Deleted] (SOLR-8235) Federated Search (new) - Merge
[ https://issues.apache.org/jira/browse/SOLR-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8235: Comment: was deleted (was: patch against SOLR 4.10.3) > Federated Search (new) - Merge > -- > > Key: SOLR-8235 > URL: https://issues.apache.org/jira/browse/SOLR-8235 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > Attachments: SOLR-8235.patch > > > This issue describes a SearchComponent for merging search results obtained > from a DJoin distributed search (see SOLR-8234) as part of federated search - > that is, distributed search over documents stored in separated instances of > SOLR (for example, one server per continent), where a single document > (identified by an agreed, common unique id) may be stored in more than one > server instance, with (possibly) differing fields and data. > In the use of this search component, it is assumed that there is a single > SOLR server (the "aggregator") that uses distributed search (shards=) to > collect documents from other SOLR servers using DJoin (see SOLR-8234). The > DJoin generates a result set containing parent documents each with child > documents having the same unique id. This merge component turns each set of > child documents into a single document conforming to the aggregator schema. > For example, suppose the aggregator schema defines a multi-valued integer > field, 'num', and three shards return field values "48", 23, and > "strawberry". Then the resulting merged field value would be [48, 23] and an > error would included for the NumberFormatException. > Custom field merge behaviour may be specified by defining custom field types > in the usual way and this is supported via a MergeAbstractFieldType class. > This issue combines with others to provide full federated search support. See > also SOLR-8234 and SOLR-8236. > – > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- 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-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Attachment: SOLR-8234.patch
some package renaming
> Federated Search (new) - DJoin
> --
>
> Key: SOLR-8234
> URL: https://issues.apache.org/jira/browse/SOLR-8234
> Project: Solr
> Issue Type: New Feature
>Reporter: Tom Winch
>Priority: Minor
> Labels: federated_search
> Fix For: 4.10.3
>
> Attachments: SOLR-8234.patch, SOLR-8234.patch, SOLR-8234.patch
>
>
> This issue describes a MergeStrategy implementation (DJoin) to facilitate
> federated search - that is, distributed search over documents stored in
> separated instances of SOLR (for example, one server per continent), where a
> single document (identified by an agreed, common unique id) may be stored in
> more than one server instance, with (possibly) differing fields and data.
> When the MergeStrategy is used in a request handler (via the included
> QParser) in combination with distributed search (shards=), documents having
> an id that has already been seen are not discarded (as per the default
> behaviour) but, instead, are collected and returned as a group of documents
> all with the same id taking a single position in the result set (this is
> implemented using parent/child documents, with an indicator field in the
> parent - see example output, below).
> Documents are sorted in the result set based on the highest ranking document
> with the same id. It is possible for a document ranking high in one shard to
> rank very low on another shard. As a consequence of this, all shards must be
> asked to return the fields for every document id in the result set (not just
> of those documents they returned), so that all the component parts of each
> document in the search result set are returned.
> As usual, search parameters are passed on to each shard. So that the shards
> do not need any additional configurations in their definition of the /select
> request handler, we use the FilterQParserSearchComponent which is configured
> to filter out the \{!djoin\} search parameter - otherwise, the target request
> handler complains about the missing query parser definition. See the example
> config, below.
> This issue combines with others to provide full federated search support. See
> also SOLR-8235 and SOLR-8236.
> Note that this is part of a new implementation of federated search as opposed
> to the older issues SOLR-3799 through SOLR-3805.
> --
> Example request handler configuration:
> {code:xml}
>class="org.apache.solr.search.federated.FilterDJoinQParserSearchComponent" />
>
>class="org.apache.solr.search.federated.DJoinQParserPlugin" />
>
>
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> {!djoin}
>
>
> filter
>
>
> {code}
> Example output:
> {code:xml}
>
>
>
> 0
> 33
>
> *:*
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> xml
> {!djoin}
> *,[shard]
>
>
>
>
> true
>
> 200
> 1973
> http://shard2/solr/core
> 1515645309629235200
>
>
> 200
> 2015
> http://shard1/solr/core
> 1515645309682712576
>
>
>
> true
>
> 100
> 873
> http://shard1/solr/core
> 1515645309629254124
>
>
> 100
> 2001
> http://shard3/solr/core
> 1515645309682792852
>
>
>
> true
>
> 300
> 1492
> http://shard2/solr/core
> 1515645309629251252
>
>
>
>
> {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...@lucene.apache.org
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents, with an indicator field in the parent - see example
output, below).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents, with an indicator field in the parent - see example
output, below).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new
[jira] [Updated] (SOLR-8235) Federated Search (new) - Merge
[ https://issues.apache.org/jira/browse/SOLR-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8235: Attachment: SOLR-8235.patch patch against SOLR 4.10.3 > Federated Search (new) - Merge > -- > > Key: SOLR-8235 > URL: https://issues.apache.org/jira/browse/SOLR-8235 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > Attachments: SOLR-8235.patch > > > This issue describes a SearchComponent for merging search results obtained > from a DJoin distributed search (see SOLR-8234) as part of federated search - > that is, distributed search over documents stored in separated instances of > SOLR (for example, one server per continent), where a single document > (identified by an agreed, common unique id) may be stored in more than one > server instance, with (possibly) differing fields and data. > In the use of this search component, it is assumed that there is a single > SOLR server (the "aggregator") that uses distributed search (shards=) to > collect documents from other SOLR servers using DJoin (see SOLR-8234). The > DJoin generates a result set containing parent documents each with child > documents having the same unique id. This merge component turns each set of > child documents into a single document conforming to the aggregator schema. > For example, suppose the aggregator schema defines a multi-valued integer > field, 'num', and three shards return field values "48", 23, and > "strawberry". Then the resulting merged field value would be [48, 23] and an > error would included for the NumberFormatException. > Custom field merge behaviour may be specified by defining custom field types > in the usual way and this is supported via a MergeAbstractFieldType class. > This issue combines with others to provide full federated search support. See > also SOLR-8234 and SOLR-8236. > – > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- 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-8235) Federated Search (new) - Merge
[ https://issues.apache.org/jira/browse/SOLR-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8235: Flags: Patch > Federated Search (new) - Merge > -- > > Key: SOLR-8235 > URL: https://issues.apache.org/jira/browse/SOLR-8235 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > Attachments: SOLR-8235.patch > > > This issue describes a SearchComponent for merging search results obtained > from a DJoin distributed search (see SOLR-8234) as part of federated search - > that is, distributed search over documents stored in separated instances of > SOLR (for example, one server per continent), where a single document > (identified by an agreed, common unique id) may be stored in more than one > server instance, with (possibly) differing fields and data. > In the use of this search component, it is assumed that there is a single > SOLR server (the "aggregator") that uses distributed search (shards=) to > collect documents from other SOLR servers using DJoin (see SOLR-8234). The > DJoin generates a result set containing parent documents each with child > documents having the same unique id. This merge component turns each set of > child documents into a single document conforming to the aggregator schema. > For example, suppose the aggregator schema defines a multi-valued integer > field, 'num', and three shards return field values "48", 23, and > "strawberry". Then the resulting merged field value would be [48, 23] and an > error would included for the NumberFormatException. > Custom field merge behaviour may be specified by defining custom field types > in the usual way and this is supported via a MergeAbstractFieldType class. > This issue combines with others to provide full federated search support. See > also SOLR-8234 and SOLR-8236. > – > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- 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-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Description:
h2. XJoin
The "xjoin" SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent,
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory
and XJoinResults, which are implemented by the user to provide the link between
SOLR and the external results source. External results and SOLR documents are
matched via a single configurable attribute (the "join field"). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
..
..
..
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix ".external." are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, .external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* Iterable getJoinIds() - this should return an ordered (ascending)
list of the join attribute values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
There is one XJoin search component per external source, and each has two main
responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
test.TestXJoinResultsFactory
id
1,2,3
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the "values" parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
..
true
xx
test_count
id,value
xjoin_test
xjoin_test
{code}
Note that, to include the list of join ids returned by the external source in
the SOLR results (likely for debug purposes), the value 'join_ids' may be
specified in the "results" parameter.
h3. XJoinQParserPlugin
This query parser plugin constructs a query from the results of the external
searches, and is based on the TermsQParserPlugin. It takes the following local
parameters:
* method - as the TermsQParserPlugin, this specifies how to build the Lucene
query based on the join ids contained in external results; one of termsFilter,
booleanQuery, automaton, or
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Description:
h2. XJoin
The "xjoin" SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent,
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory
and XJoinResults, which are implemented by the user to provide the link between
SOLR and the external results source. External results and SOLR documents are
matched via a single configurable attribute (the "join field"). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
..
..
..
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix ".external." are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, .external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* Iterable getJoinIds() - this should return an ordered (ascending)
list of the join attribute values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
There is one XJoin search component per external source, and each has two main
responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
test.TestXJoinResultsFactory
id
1,2,3
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the "values" parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
..
true
xx
test_count
id,value
xjoin_test
xjoin_test
{code}
Note that, to include the list of join ids returned by the external source in
the SOLR results (likely for debug purposes), the value 'join_ids' may be
specified in the "results" parameter.
h3. XJoinQParserPlugin
This query parser plugin constructs a query from the results of the external
searches, and is based on the TermsQParserPlugin. It takes the following local
parameters:
* method - as the TermsQParserPlugin, this specifies how to build the Lucene
query based on the join ids contained in external results; one of termsFilter,
booleanQuery, automaton, or
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Attachment: SOLR-8234.patch
Patch including in parent docs and improved unit test
> Federated Search (new) - DJoin
> --
>
> Key: SOLR-8234
> URL: https://issues.apache.org/jira/browse/SOLR-8234
> Project: Solr
> Issue Type: New Feature
>Reporter: Tom Winch
>Priority: Minor
> Labels: federated_search
> Fix For: 4.10.3
>
> Attachments: SOLR-8234.patch, SOLR-8234.patch
>
>
> This issue describes a MergeStrategy implementation (DJoin) to facilitate
> federated search - that is, distributed search over documents stored in
> separated instances of SOLR (for example, one server per continent), where a
> single document (identified by an agreed, common unique id) may be stored in
> more than one server instance, with (possibly) differing fields and data.
> When the MergeStrategy is used in a request handler (via the included
> QParser) in combination with distributed search (shards=), documents having
> an id that has already been seen are not discarded (as per the default
> behaviour) but, instead, are collected and returned as a group of documents
> all with the same id taking a single position in the result set (this is
> implemented using parent/child documents, with an indicator field in the
> parent - see example output, below).
> Documents are sorted in the result set based on the highest ranking document
> with the same id. It is possible for a document ranking high in one shard to
> rank very low on another shard. As a consequence of this, all shards must be
> asked to return the fields for every document id in the result set (not just
> of those documents they returned), so that all the component parts of each
> document in the search result set are returned.
> As usual, search parameters are passed on to each shard. So that the shards
> do not need any additional configurations in their definition of the /select
> request handler, we use the FilterQParserSearchComponent which is configured
> to filter out the \{!djoin\} search parameter - otherwise, the target request
> handler complains about the missing query parser definition. See the example
> config, below.
> This issue combines with others to provide full federated search support. See
> also SOLR-8235 and SOLR-8236.
> Note that this is part of a new implementation of federated search as opposed
> to the older issues SOLR-3799 through SOLR-3805.
> --
> Example request handler configuration:
> {code:xml}
>class="org.apache.solr.search.djoin.FilterQParserSearchComponent">
> djoin
>
>
>class="org.apache.solr.search.djoin.DJoinQParserPlugin" />
>
> class="org.apache.solr.search.djoin.LocalShardHandlerFactory" />
>
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> {!djoin}
>
>
> filter
>
>
> {code}
> Example output:
> {code:xml}
>
>
>
> 0
> 33
>
> *:*
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> xml
> {!djoin}
> *,[shard]
>
>
>
>
> true
>
> 200
> 1973
> http://shard2/solr/core
> 1515645309629235200
>
>
> 200
> 2015
> http://shard1/solr/core
> 1515645309682712576
>
>
>
> true
>
> 100
> 873
> http://shard1/solr/core
> 1515645309629254124
>
>
> 100
> 2001
> http://shard3/solr/core
> 1515645309682792852
>
>
>
> true
>
> 300
> 1492
> http://shard2/solr/core
> 1515645309629251252
>
>
>
>
> {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...@lucene.apache.org
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents, with an indicator field in the parent - see example
output, below).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents, with an indicator field in the parent - see example
output, below).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Attachment: SOLR-8234.patch
> Federated Search (new) - DJoin
> --
>
> Key: SOLR-8234
> URL: https://issues.apache.org/jira/browse/SOLR-8234
> Project: Solr
> Issue Type: New Feature
>Reporter: Tom Winch
>Priority: Minor
> Labels: federated_search
> Fix For: 4.10.3
>
> Attachments: SOLR-8234.patch, SOLR-8234.patch
>
>
> This issue describes a MergeStrategy implementation (DJoin) to facilitate
> federated search - that is, distributed search over documents stored in
> separated instances of SOLR (for example, one server per continent), where a
> single document (identified by an agreed, common unique id) may be stored in
> more than one server instance, with (possibly) differing fields and data.
> When the MergeStrategy is used in a request handler (via the included
> QParser) in combination with distributed search (shards=), documents having
> an id that has already been seen are not discarded (as per the default
> behaviour) but, instead, are collected and returned as a group of documents
> all with the same id taking a single position in the result set (this is
> implemented using parent/child documents, with an indicator field in the
> parent - see example output, below).
> Documents are sorted in the result set based on the highest ranking document
> with the same id. It is possible for a document ranking high in one shard to
> rank very low on another shard. As a consequence of this, all shards must be
> asked to return the fields for every document id in the result set (not just
> of those documents they returned), so that all the component parts of each
> document in the search result set are returned.
> As usual, search parameters are passed on to each shard. So that the shards
> do not need any additional configurations in their definition of the /select
> request handler, we use the FilterQParserSearchComponent which is configured
> to filter out the \{!djoin\} search parameter - otherwise, the target request
> handler complains about the missing query parser definition. See the example
> config, below.
> This issue combines with others to provide full federated search support. See
> also SOLR-8235 and SOLR-8236.
> Note that this is part of a new implementation of federated search as opposed
> to the older issues SOLR-3799 through SOLR-3805.
> --
> Example request handler configuration:
> {code:xml}
>class="org.apache.solr.search.djoin.FilterDJoinQParserSearchComponent" />
>
>class="org.apache.solr.search.djoin.DJoinQParserPlugin" />
>
> class="org.apache.solr.search.djoin.LocalShardHandlerFactory" />
>
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> {!djoin}
>
>
> filter
>
>
> {code}
> Example output:
> {code:xml}
>
>
>
> 0
> 33
>
> *:*
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> xml
> {!djoin}
> *,[shard]
>
>
>
>
> true
>
> 200
> 1973
> http://shard2/solr/core
> 1515645309629235200
>
>
> 200
> 2015
> http://shard1/solr/core
> 1515645309682712576
>
>
>
> true
>
> 100
> 873
> http://shard1/solr/core
> 1515645309629254124
>
>
> 100
> 2001
> http://shard3/solr/core
> 1515645309682792852
>
>
>
> true
>
> 300
> 1492
> http://shard2/solr/core
> 1515645309629251252
>
>
>
>
> {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...@lucene.apache.org
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Attachment: (was: SOLR-8234.patch)
> Federated Search (new) - DJoin
> --
>
> Key: SOLR-8234
> URL: https://issues.apache.org/jira/browse/SOLR-8234
> Project: Solr
> Issue Type: New Feature
>Reporter: Tom Winch
>Priority: Minor
> Labels: federated_search
> Fix For: 4.10.3
>
> Attachments: SOLR-8234.patch, SOLR-8234.patch
>
>
> This issue describes a MergeStrategy implementation (DJoin) to facilitate
> federated search - that is, distributed search over documents stored in
> separated instances of SOLR (for example, one server per continent), where a
> single document (identified by an agreed, common unique id) may be stored in
> more than one server instance, with (possibly) differing fields and data.
> When the MergeStrategy is used in a request handler (via the included
> QParser) in combination with distributed search (shards=), documents having
> an id that has already been seen are not discarded (as per the default
> behaviour) but, instead, are collected and returned as a group of documents
> all with the same id taking a single position in the result set (this is
> implemented using parent/child documents, with an indicator field in the
> parent - see example output, below).
> Documents are sorted in the result set based on the highest ranking document
> with the same id. It is possible for a document ranking high in one shard to
> rank very low on another shard. As a consequence of this, all shards must be
> asked to return the fields for every document id in the result set (not just
> of those documents they returned), so that all the component parts of each
> document in the search result set are returned.
> As usual, search parameters are passed on to each shard. So that the shards
> do not need any additional configurations in their definition of the /select
> request handler, we use the FilterQParserSearchComponent which is configured
> to filter out the \{!djoin\} search parameter - otherwise, the target request
> handler complains about the missing query parser definition. See the example
> config, below.
> This issue combines with others to provide full federated search support. See
> also SOLR-8235 and SOLR-8236.
> Note that this is part of a new implementation of federated search as opposed
> to the older issues SOLR-3799 through SOLR-3805.
> --
> Example request handler configuration:
> {code:xml}
>class="org.apache.solr.search.djoin.FilterDJoinQParserSearchComponent" />
>
>class="org.apache.solr.search.djoin.DJoinQParserPlugin" />
>
> class="org.apache.solr.search.djoin.LocalShardHandlerFactory" />
>
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> {!djoin}
>
>
> filter
>
>
> {code}
> Example output:
> {code:xml}
>
>
>
> 0
> 33
>
> *:*
>name="shards">http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
> true
> xml
> {!djoin}
> *,[shard]
>
>
>
>
> true
>
> 200
> 1973
> http://shard2/solr/core
> 1515645309629235200
>
>
> 200
> 2015
> http://shard1/solr/core
> 1515645309682712576
>
>
>
> true
>
> 100
> 873
> http://shard1/solr/core
> 1515645309629254124
>
>
> 100
> 2001
> http://shard3/solr/core
> 1515645309682792852
>
>
>
> true
>
> 300
> 1492
> http://shard2/solr/core
> 1515645309629251252
>
>
>
>
> {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...@lucene.apache.org
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
\{!djoin\}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
\{!djoin\}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the {!djoin} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the {{/select}}
request handler, we use the {{FilterQParserSearchComponent}} which is
configured to filter out the {{{!djoin}}} search parameter - otherwise, the
target request handler complains about the missing query parser definition. See
the example config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
[jira] [Updated] (SOLR-8235) Federated Search (new) - Merge
[ https://issues.apache.org/jira/browse/SOLR-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8235: Flags: (was: Patch) > Federated Search (new) - Merge > -- > > Key: SOLR-8235 > URL: https://issues.apache.org/jira/browse/SOLR-8235 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > > This issue describes a SearchComponent for merging search results obtained > from a DJoin distributed search (see SOLR-8234) as part of federated search - > that is, distributed search over documents stored in separated instances of > SOLR (for example, one server per continent), where a single document > (identified by an agreed, common unique id) may be stored in more than one > server instance, with (possibly) differing fields and data. > In the use of this search component, it is assumed that there is a single > SOLR server (the "aggregator") that uses distributed search (shards=) to > collect documents from other SOLR servers using DJoin (see SOLR-8234). The > DJoin generates a result set containing parent documents each with child > documents having the same unique id. This merge component turns each set of > child documents into a single document conforming to the aggregator schema. > For example, suppose the aggregator schema defines a multi-valued integer > field, 'num', and three shards return field values "48", 23, and > "strawberry". Then the resulting merged field value would be [48, 23] and an > error would included for the NumberFormatException. > Custom field merge behaviour may be specified by defining custom field types > in the usual way and this is supported via a MergeAbstractFieldType class. > This issue combines with others to provide full federated search support. See > also SOLR-8234 and SOLR-8236. > – > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- 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-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{{
djoin
shard/1,shard/2,shard/3
false
{!djoin}
filter
}}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
--
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
> Federated Search (new) - DJoin
> --
>
> Key: SOLR-8234
> URL: https://issues.apache.org/jira/browse/SOLR-8234
> Project: Solr
> Issue Type: New Feature
>Reporter: Tom Winch
>Priority: Minor
> Labels: federated_search
> Fix For: 4.10.3
>
> Attachments: SOLR-8234.patch
>
>
> This issue describes a MergeStrategy implementation (DJoin) to facilitate
> federated search - that is, distributed search over documents stored in
> separated instances of SOLR (for example, one server per continent), where a
> single document (identified by an agreed, common unique id) may be stored in
> more than one server instance, with (possibly) differing fields and data.
> When the MergeStrategy is used in a request handler (via the included
> QParser) in combination with distributed search (shards=), documents having
> an id that has already been seen are not discarded (as per the default
> behaviour) but, instead, are collected and returned as a group of documents
> all with the same id taking a single position in the result set (this is
> implemented using parent/child documents).
> Documents are sorted in the result set based on the highest ranking document
> with the same id. It is possible for a document ranking high in one shard to
> rank very low on another shard. As a consequence of this, all shards must be
> asked to return the fields for every document id in the result set (not just
> of those documents they returned), so that all the component parts of each
> document in the search result set are
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the {!djoin} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the {{/select}}
request handler, we use the {{FilterQParserSearchComponent}} which is
configured to filter out the {{{!djoin}}} search parameter - otherwise, the
target request handler complains about the missing query parser definition. See
the example config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Flags: Patch
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-trunk,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{{
djoin
shard/1,shard/2,shard/3
false
{!djoin}
filter
}}
> Federated Search (new) - DJoin
> --
>
> Key: SOLR-8234
> URL: https://issues.apache.org/jira/browse/SOLR-8234
> Project: Solr
> Issue Type: New Feature
>Reporter: Tom Winch
>Priority: Minor
> Labels: federated_search
> Fix For: 4.10.3
>
> Attachments: SOLR-8234.patch
>
>
> This issue describes a MergeStrategy implementation (DJoin) to facilitate
> federated search - that is, distributed search over documents stored in
> separated instances of SOLR (for example, one server per continent), where a
> single document
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
\{!djoin\}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
\{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
\{!djoin\}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[
https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-8234:
Description:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents, with an indicator field in the parent - see example
output, below).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older issues SOLR-3799 through SOLR-3805.
--
Example request handler configuration:
{code:xml}
djoin
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
{!djoin}
filter
{code}
Example output:
{code:xml}
0
33
*:*
http://shard1/solr/core,http://shard2/solr/core,http://shard3/solr/core
true
xml
{!djoin}
*,[shard]
true
200
1973
http://shard2/solr/core
1515645309629235200
200
2015
http://shard1/solr/core
1515645309682712576
true
100
873
http://shard1/solr/core
1515645309629254124
100
2001
http://shard3/solr/core
1515645309682792852
true
300
1492
http://shard2/solr/core
1515645309629251252
{code}
was:
This issue describes a MergeStrategy implementation (DJoin) to facilitate
federated search - that is, distributed search over documents stored in
separated instances of SOLR (for example, one server per continent), where a
single document (identified by an agreed, common unique id) may be stored in
more than one server instance, with (possibly) differing fields and data.
When the MergeStrategy is used in a request handler (via the included QParser)
in combination with distributed search (shards=), documents having an id that
has already been seen are not discarded (as per the default behaviour) but,
instead, are collected and returned as a group of documents all with the same
id taking a single position in the result set (this is implemented using
parent/child documents).
Documents are sorted in the result set based on the highest ranking document
with the same id. It is possible for a document ranking high in one shard to
rank very low on another shard. As a consequence of this, all shards must be
asked to return the fields for every document id in the result set (not just of
those documents they returned), so that all the component parts of each
document in the search result set are returned.
As usual, search parameters are passed on to each shard. So that the shards do
not need any additional configurations in their definition of the /select
request handler, we use the FilterQParserSearchComponent which is configured to
filter out the \{!djoin\} search parameter - otherwise, the target request
handler complains about the missing query parser definition. See the example
config, below.
This issue combines with others to provide full federated search support. See
also SOLR-8235 and SOLR-8236.
Note that this is part of a new implementation of federated search as opposed
to the older
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[ https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8234: Attachment: SOLR-8234.patch Patch against 4.10.3 > Federated Search (new) - DJoin > -- > > Key: SOLR-8234 > URL: https://issues.apache.org/jira/browse/SOLR-8234 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > Attachments: SOLR-8234.patch > > > This issue describes a MergeStrategy implementation (DJoin) to facilitate > federated search - that is, distributed search over documents stored in > separated instances of SOLR (for example, one server per continent), where a > single document (identified by an agreed, common unique id) may be stored in > more than one server instance, with (possibly) differing fields and data. > When the MergeStrategy is used in a request handler (via the included > QParser) in combination with distributed search (shards=), documents having > an id that has already been seen are not discarded (as per the default > behaviour) but, instead, are collected and returned as a group of documents > all with the same id taking a single position in the result set (this is > implemented using parent/child documents). > Documents are sorted in the result set based on the highest ranking document > with the same id. It is possible for a document ranking high in one shard to > rank very low on another shard. As a consequence of this, all shards must be > asked to return the fields for every document id in the result set (not just > of those documents they returned), so that all the component parts of each > document in the search result set are returned. > This issue combines with others to provide full federated search support. See > also SOLR-8235 and SOLR-8236. > -- > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- 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-8235) Federated Search (new) - Merge
[ https://issues.apache.org/jira/browse/SOLR-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8235: Description: This issue describes a SearchComponent for merging search results obtained from a DJoin distributed search (see SOLR-8234) as part of federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. In the use of this search component, it is assumed that there is a single SOLR server (the "aggregator") that uses distributed search (shards=) to collect documents from other SOLR servers using DJoin (see SOLR-8234). The DJoin generates a result set containing parent documents each with child documents having the same unique id. This merge component turns each set of child documents into a single document conforming to the aggregator schema. For example, suppose the aggregator schema defines a multi-valued integer field, 'num', and three shards return field values "48", 23, and "strawberry". Then the resulting merged field value would be [48, 23] and an error would included for the NumberFormatException. Custom field merge behaviour may be specified by defining custom field types in the usual way and this is supported via a MergeAbstractFieldType class. This issue combines with others to provide full federated search support. See also SOLR-8234 and SOLR-8236. – Note that this is part of a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. was: This issue describes a SearchComponent for merging search results obtained from a DJoin distributed search (see SOLR-8234) as part of federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. In the use of this search component, it is assumed that there is a single SOLR server (the "aggregator") that uses distributed search (shards=) to collect documents from other SOLR servers using DJoin (see SOLR-8234). The DJoin generates a result set containing parent documents each with child documents having the same unique id. This merge component turns each set of child documents into a single document conforming to the aggregator schema. For example, suppose the aggregator schema defines a multi-valued integer field, 'num', and three shards return field values "48", 23, and "strawberry". Then the resulting merged field value would be [48, 23] and an error would included for the NumberFormatException. Custom field merge behaviour may be specified by defining custom field types in the usual way and this is supported via a MergeAbstractFieldType class. This issue combines with others to provide full federated search support. See also SOLR-8234 and SOLR-8236. – Note that this is part of a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. > Federated Search (new) - Merge > -- > > Key: SOLR-8235 > URL: https://issues.apache.org/jira/browse/SOLR-8235 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > > This issue describes a SearchComponent for merging search results obtained > from a DJoin distributed search (see SOLR-8234) as part of federated search - > that is, distributed search over documents stored in separated instances of > SOLR (for example, one server per continent), where a single document > (identified by an agreed, common unique id) may be stored in more than one > server instance, with (possibly) differing fields and data. > In the use of this search component, it is assumed that there is a single > SOLR server (the "aggregator") that uses distributed search (shards=) to > collect documents from other SOLR servers using DJoin (see SOLR-8234). The > DJoin generates a result set containing parent documents each with child > documents having the same unique id. This merge component turns each set of > child documents into a single document conforming to the aggregator schema. > For example, suppose the aggregator schema defines a multi-valued integer > field, 'num', and three shards return field values "48", 23, and > "strawberry". Then the resulting merged field value would be [48, 23] and an > error would included for the NumberFormatException. > Custom field merge behaviour may be specified by defining custom field types > in the usual way and
[jira] [Updated] (SOLR-8236) Federated Search (new) - NumFound
[ https://issues.apache.org/jira/browse/SOLR-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8236: Description: This issue describes a search component for estimating numFounds in federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When documents are present on more than one distributed server, which is normally the case in the federated search situation, then the numFound reported by the search is incorrect. For small result sets we may return all the document ids matching the query from each server, in order to compute an exact numFound. For large result sets this is impractical, and the numFound may be estimated using statistical techniques. Statistical techniques may be driven by the following heuristic: if two shards always return the same numFound for queries, then they contain the same document ids, and the combined numFound is the same as for each. On the other hand, if two shards always return different numFounds for queries, then they likely contain independent document ids, and the numFounds should be summed. This issue combines with others to provide full federated search support. See also SOLR-8234 and SOLR-8235. – Note that this is part of a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. > Federated Search (new) - NumFound > - > > Key: SOLR-8236 > URL: https://issues.apache.org/jira/browse/SOLR-8236 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > > This issue describes a search component for estimating numFounds in federated > search - that is, distributed search over documents stored in separated > instances of SOLR (for example, one server per continent), where a single > document (identified by an agreed, common unique id) may be stored in more > than one server instance, with (possibly) differing fields and data. > When documents are present on more than one distributed server, which is > normally the case in the federated search situation, then the numFound > reported by the search is incorrect. For small result sets we may return all > the document ids matching the query from each server, in order to compute an > exact numFound. For large result sets this is impractical, and the numFound > may be estimated using statistical techniques. > Statistical techniques may be driven by the following heuristic: if two > shards always return the same numFound for queries, then they contain the > same document ids, and the combined numFound is the same as for each. On the > other hand, if two shards always return different numFounds for queries, then > they likely contain independent document ids, and the numFounds should be > summed. > This issue combines with others to provide full federated search support. See > also SOLR-8234 and SOLR-8235. > – > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- 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-8234) Federated Search (new) - DJoin
[ https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8234: Description: This issue describes a MergeStrategy implementation (DJoin) to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also SOLR-8235 and SOLR-8236. -- Note that this is part of a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. was: This issue describes a MergeStrategy implementation (DJoin) to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also... -- Note that this is part of a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. > Federated Search (new) - DJoin > -- > > Key: SOLR-8234 > URL: https://issues.apache.org/jira/browse/SOLR-8234 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > > This issue describes a MergeStrategy implementation (DJoin) to facilitate > federated search - that is, distributed search over documents stored in > separated instances of SOLR (for example, one server per continent), where a > single document (identified by an agreed, common unique id) may be stored in > more than one server instance, with (possibly) differing fields and data. > When the MergeStrategy is used in a request handler (via the included > QParser) in combination with distributed search (shards=), documents having > an id that has already been seen are not discarded (as per the default > behaviour) but, instead, are collected and returned as a group of documents > all with the same id taking a single position in the result set (this is > implemented using parent/child documents). > Documents are sorted in the result set based on the highest ranking document > with the same id. It is possible for a document ranking high in one shard to > rank very low on another shard. As a consequence of this, all shards must be > asked to return the fields of for every document id in the result set (not > just of those documents they returned), so that all the component parts of > each document in the search result set are returned. > This issue combines with others to provide full federated search support. See > also SOLR-8235 and SOLR-8236. > -- > Note that this is part of a new implementation of federated search as opposed > to the older
[jira] [Updated] (SOLR-8235) Federated Search (new) - Merge
[ https://issues.apache.org/jira/browse/SOLR-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8235: Labels: federated_search (was: ) Description: This issue describes a SearchComponent for merging search results obtained from a DJoin distributed search (see SOLR-8234) as part of federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. In the use of this search component, it is assumed that there is a single SOLR server (the "aggregator") that uses distributed search (shards=) to collect documents from other SOLR servers using DJoin (see SOLR-8234). The DJoin generates a result set containing parent documents each with child documents having the same unique id. This merge component turns each set of child documents into a single document conforming to the aggregator schema. For example, suppose the aggregator schema defines a multi-valued integer field, 'num', and three shards return field values "48", 23, and "strawberry". Then the resulting merged field value would be [48, 23] and an error would included for the NumberFormatException. Custom field merge behaviour may be specified by defining custom field types in the usual way and this is supported via a MergeAbstractFieldType class. This issue combines with others to provide full federated search support. See also SOLR-8234 and SOLR-8236. – Note that this is part of a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. > Federated Search (new) - Merge > -- > > Key: SOLR-8235 > URL: https://issues.apache.org/jira/browse/SOLR-8235 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > > This issue describes a SearchComponent for merging search results obtained > from a DJoin distributed search (see SOLR-8234) as part of federated search - > that is, distributed search over documents stored in separated instances of > SOLR (for example, one server per continent), where a single document > (identified by an agreed, common unique id) may be stored in more than one > server instance, with (possibly) differing fields and data. > In the use of this search component, it is assumed that there is a single > SOLR server (the "aggregator") that uses distributed search (shards=) to > collect documents from other SOLR servers using DJoin (see SOLR-8234). The > DJoin generates a result set containing parent documents each with child > documents having the same unique id. This merge component turns each set of > child documents into a single document conforming to the aggregator schema. > For example, suppose the aggregator schema defines a multi-valued integer > field, 'num', and three shards return field values "48", 23, and > "strawberry". Then the resulting merged field value would be [48, 23] and an > error would included for the NumberFormatException. > Custom field merge behaviour may be specified by defining custom field types > in the usual way and this is supported via a MergeAbstractFieldType class. > This issue combines with others to provide full federated search support. See > also SOLR-8234 and SOLR-8236. > – > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- 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-8234) Federated Search (new) - DJoin
[ https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8234: Description: This issue describes a MergeStrategy implementation (DJoin) to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also... -- Note that this is a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. was: This issue describes a MergeStrategy implementation (DJoin) to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also... -- Note that this is a new implementation of federated search as opposed to the older issues SOLR-3799 to 3805. > Federated Search (new) - DJoin > -- > > Key: SOLR-8234 > URL: https://issues.apache.org/jira/browse/SOLR-8234 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > > This issue describes a MergeStrategy implementation (DJoin) to facilitate > federated search - that is, distributed search over documents stored in > separated instances of SOLR (for example, one server per continent), where a > single document (identified by an agreed, common unique id) may be stored in > more than one server instance, with (possibly) differing fields and data. > When the MergeStrategy is used in a request handler (via the included > QParser) in combination with distributed search (shards=), documents having > an id that has already been seen are not discarded (as per the default > behaviour) but, instead, are collected and returned as a group of documents > all with the same id taking a single position in the result set (this is > implemented using parent/child documents). > Documents are sorted in the result set based on the highest ranking document > with the same id. It is possible for a document ranking high in one shard to > rank very low on another shard. As a consequence of this, all shards must be > asked to return the fields of for every document id in the result set (not > just of those documents they returned), so that all the component parts of > each document in the search result set are returned. > This issue combines with others to provide full federated search support. See > also... > -- > Note that this is a new implementation of federated search as opposed to the > older issues SOLR-3799 through SOLR-3805. -- This message was sent by Atlassian JIRA
[jira] [Updated] (SOLR-8234) Federated Search (new) - DJoin
[ https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8234: Description: This issue describes a MergeStrategy implementation (DJoin) to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also... -- Note that this is a new implementation of federated search as opposed to the older issues SOLR-3799 to 3805. was: This issue describes a MergeStrategy implementation to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also... -- Note that this is a new implementation of federated search as opposed to the older issues SOLR-3799 to 3805. > Federated Search (new) - DJoin > -- > > Key: SOLR-8234 > URL: https://issues.apache.org/jira/browse/SOLR-8234 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > > This issue describes a MergeStrategy implementation (DJoin) to facilitate > federated search - that is, distributed search over documents stored in > separated instances of SOLR (for example, one server per continent), where a > single document (identified by an agreed, common unique id) may be stored in > more than one server instance, with (possibly) differing fields and data. > When the MergeStrategy is used in a request handler (via the included > QParser) in combination with distributed search (shards=), documents having > an id that has already been seen are not discarded (as per the default > behaviour) but, instead, are collected and returned as a group of documents > all with the same id taking a single position in the result set (this is > implemented using parent/child documents). > Documents are sorted in the result set based on the highest ranking document > with the same id. It is possible for a document ranking high in one shard to > rank very low on another shard. As a consequence of this, all shards must be > asked to return the fields of for every document id in the result set (not > just of those documents they returned), so that all the component parts of > each document in the search result set are returned. > This issue combines with others to provide full federated search support. See > also... > -- > Note that this is a new implementation of federated search as opposed to the > older issues SOLR-3799 to 3805. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SOLR-8235) Federated Search (new) - Merge
Tom Winch created SOLR-8235: --- Summary: Federated Search (new) - Merge Key: SOLR-8235 URL: https://issues.apache.org/jira/browse/SOLR-8235 Project: Solr Issue Type: New Feature Affects Versions: 4.10.3 Reporter: Tom Winch Priority: Minor -- 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-8234) Federated Search (new) - DJoin
[ https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8234: Description: This issue describes a MergeStrategy implementation (DJoin) to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also... -- Note that this is part of a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. was: This issue describes a MergeStrategy implementation (DJoin) to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also... -- Note that this is a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. > Federated Search (new) - DJoin > -- > > Key: SOLR-8234 > URL: https://issues.apache.org/jira/browse/SOLR-8234 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > > This issue describes a MergeStrategy implementation (DJoin) to facilitate > federated search - that is, distributed search over documents stored in > separated instances of SOLR (for example, one server per continent), where a > single document (identified by an agreed, common unique id) may be stored in > more than one server instance, with (possibly) differing fields and data. > When the MergeStrategy is used in a request handler (via the included > QParser) in combination with distributed search (shards=), documents having > an id that has already been seen are not discarded (as per the default > behaviour) but, instead, are collected and returned as a group of documents > all with the same id taking a single position in the result set (this is > implemented using parent/child documents). > Documents are sorted in the result set based on the highest ranking document > with the same id. It is possible for a document ranking high in one shard to > rank very low on another shard. As a consequence of this, all shards must be > asked to return the fields of for every document id in the result set (not > just of those documents they returned), so that all the component parts of > each document in the search result set are returned. > This issue combines with others to provide full federated search support. See > also... > -- > Note that this is part of a new implementation of federated search as opposed > to the older issues SOLR-3799 through SOLR-3805. -- This message
[jira] [Created] (SOLR-8236) Federated Search (new) - NumFound
Tom Winch created SOLR-8236: --- Summary: Federated Search (new) - NumFound Key: SOLR-8236 URL: https://issues.apache.org/jira/browse/SOLR-8236 Project: Solr Issue Type: New Feature Reporter: Tom Winch Priority: Minor -- 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-8235) Federated Search (new) - Merge
[ https://issues.apache.org/jira/browse/SOLR-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8235: Affects Version/s: (was: 4.10.3) Fix Version/s: 4.10.3 > Federated Search (new) - Merge > -- > > Key: SOLR-8235 > URL: https://issues.apache.org/jira/browse/SOLR-8235 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Fix For: 4.10.3 > > -- 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-8234) Federated Search (new) - DJoin
[ https://issues.apache.org/jira/browse/SOLR-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-8234: Description: This issue describes a MergeStrategy implementation (DJoin) to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also SOLR-8235 and SOLR-8236. -- Note that this is part of a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. was: This issue describes a MergeStrategy implementation (DJoin) to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also SOLR-8235 and SOLR-8236. -- Note that this is part of a new implementation of federated search as opposed to the older issues SOLR-3799 through SOLR-3805. > Federated Search (new) - DJoin > -- > > Key: SOLR-8234 > URL: https://issues.apache.org/jira/browse/SOLR-8234 > Project: Solr > Issue Type: New Feature >Reporter: Tom Winch >Priority: Minor > Labels: federated_search > Fix For: 4.10.3 > > > This issue describes a MergeStrategy implementation (DJoin) to facilitate > federated search - that is, distributed search over documents stored in > separated instances of SOLR (for example, one server per continent), where a > single document (identified by an agreed, common unique id) may be stored in > more than one server instance, with (possibly) differing fields and data. > When the MergeStrategy is used in a request handler (via the included > QParser) in combination with distributed search (shards=), documents having > an id that has already been seen are not discarded (as per the default > behaviour) but, instead, are collected and returned as a group of documents > all with the same id taking a single position in the result set (this is > implemented using parent/child documents). > Documents are sorted in the result set based on the highest ranking document > with the same id. It is possible for a document ranking high in one shard to > rank very low on another shard. As a consequence of this, all shards must be > asked to return the fields for every document id in the result set (not just > of those documents they returned), so that all the component parts of each > document in the search result set are returned. > This issue combines with others to provide full federated search support. See > also SOLR-8235 and SOLR-8236. > -- > Note that this is part of a new implementation of federated search as opposed > to
[jira] [Created] (SOLR-8234) Federated Search (new) - DJoin
Tom Winch created SOLR-8234: --- Summary: Federated Search (new) - DJoin Key: SOLR-8234 URL: https://issues.apache.org/jira/browse/SOLR-8234 Project: Solr Issue Type: New Feature Reporter: Tom Winch Priority: Minor Fix For: 4.10.3 This issue describes a MergeStrategy implementation to facilitate federated search - that is, distributed search over documents stored in separated instances of SOLR (for example, one server per continent), where a single document (identified by an agreed, common unique id) may be stored in more than one server instance, with (possibly) differing fields and data. When the MergeStrategy is used in a request handler (via the included QParser) in combination with distributed search (shards=), documents having an id that has already been seen are not discarded (as per the default behaviour) but, instead, are collected and returned as a group of documents all with the same id taking a single position in the result set (this is implemented using parent/child documents). Documents are sorted in the result set based on the highest ranking document with the same id. It is possible for a document ranking high in one shard to rank very low on another shard. As a consequence of this, all shards must be asked to return the fields of for every document id in the result set (not just of those documents they returned), so that all the component parts of each document in the search result set are returned. This issue combines with others to provide full federated search support. See also... -- Note that this is a new implementation of federated search as opposed to the older issues SOLR-3799 to 3805. -- 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-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Description:
h2. XJoin
The "xjoin" SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent,
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory
and XJoinResults, which are implemented by the user to provide the link between
SOLR and the external results source. External results and SOLR documents are
matched via a single configurable attribute (the "join field"). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
..
..
..
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix ".external." are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, .external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* Iterable getJoinIds() - this should return an ordered (ascending)
list of the join attribute values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
There is one XJoin search component per external source, and each has two main
responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
test.TestXJoinResultsFactory
id
1,2,3
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the "values" parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
..
true
xx
test_count
id,value
xjoin_test
xjoin_test
{code}
Note that, to include the list of join ids returned by the external source in
the SOLR results (likely for debug purposes), the value 'join_ids' may be
specified in the "results" parameter.
h3. XJoinQParserPlugin
This query parser plugin constructs a query from the results of the external
searches, and is based on the TermsQParserPlugin. It takes the following local
parameters:
* method - as the TermsQParserPlugin, this specifies how to build the Lucene
query based on the join ids contained in external results; one of termsFilter,
booleanQuery, automaton, or
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch-trunk
Many-many support.
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-trunk,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch
Many-to-many support
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-trunk,
> SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return an ordered (ascending)
> list of the join attribute values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch
Very minor update to exclude 'class' from automatic method choice
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return the join attribute
> values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of attributes from results objects
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch-trunk
Very minor update to exclude 'class' from automatic method detection
> xjoin - join data from external sources
> ---
>
> Key: SOLR-7341
> URL: https://issues.apache.org/jira/browse/SOLR-7341
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.10.3
>Reporter: Tom Winch
>Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
> SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch-trunk, SOLR-7341.patch-trunk
>
>
> h2. XJoin
> The "xjoin" SOLR contrib allows external results to be joined with SOLR
> results in a query and the SOLR result set to be filtered by the results of
> an external query. Values from the external results are made available in the
> SOLR results and may also be used to boost the scores of corresponding
> documents during the search. The contrib consists of the Java classes
> XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
> associated classes), which must be configured in solrconfig.xml, and the
> interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
> user to provide the link between SOLR and the external results source.
> External results and SOLR documents are matched via a single configurable
> attribute (the "join field"). The contrib JAR solr-xjoin-4.10.3.jar contains
> these classes and interfaces and should be included in SOLR's class path from
> solrconfig.xml, as should a JAR containing the user implementations of the
> previously mentioned interfaces. For example:
> {code:xml}
>
> ..
>
>/>
> ..
>
>
> ..
>
> {code}
> h2. Java classes and interfaces
> h3. XJoinResultsFactory
> The user implementation of this interface is responsible for connecting to an
> external source to perform a query (or otherwise collect results). Parameters
> with prefix ".external." are passed from the SOLR query URL
> to pararameterise the search. The interface has the following methods:
> * void init(NamedList args) - this is called during SOLR initialisation, and
> passed parameters from the search component configuration (see below)
> * XJoinResults getResults(SolrParams params) - this is called during a SOLR
> search to generate external results, and is passed parameters from the SOLR
> query URL (as above)
> For example, the implementation might perform queries of an external source
> based on the 'q' SOLR query URL parameter (in full, name>.external.q).
> h3. XJoinResults
> A user implementation of this interface is returned by the getResults()
> method of the XJoinResultsFactory implementation. It has methods:
> * Object getResult(String joinId) - this should return a particular result
> given the value of the join attribute
> * Iterable getJoinIds() - this should return the join attribute
> values for all results of the external search
> h3. XJoinSearchComponent
> This is the central Java class of the contrib. It is a SOLR search component,
> configured in solrconfig.xml and included in one or more SOLR request
> handlers. There is one XJoin search component per external source, and each
> has two main responsibilities:
> * Before the SOLR search, it connects to the external source and retrieves
> results, storing them in the SOLR request context
> * After the SOLR search, it matches SOLR document in the results set and
> external results via the join field, adding attributes from the external
> results to documents in the SOLR results set
> It takes the following initialisation parameters:
> * factoryClass - this specifies the user-supplied class implementing
> XJoinResultsFactory, used to generate external results
> * joinField - this specifies the attribute on which to join between SOLR
> documents and external results
> * external - this parameter set is passed to configure the
> XJoinResultsFactory implementation
> For example, in solrconfig.xml:
> {code:xml}
> class="org.apache.solr.search.xjoin.XJoinSearchComponent">
> test.TestXJoinResultsFactory
> id
>
> 1,2,3
>
>
> {code}
> Here, the search component instantiates a new TextXJoinResultsFactory during
> initialisation, and passes it the "values" parameter (1, 2, 3) to configure
> it. To properly use the XJoinSearchComponent in a request handler, it must be
> included at the start and end of the component list, and may be configured
> with the following query parameters:
> * results - a comma-separated list of attributes from the XJoinResults
> implementation (created by the factory at search time) to be included in the
> SOLR results
> * fl - a comma-separated list of
[jira] [Commented] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14626373#comment-14626373
]
Tom Winch commented on SOLR-7341:
-
Running against a 'toy' XJoinResultsFactory implementation (that just parrots
back join ids), and an index of about 6k documents, a straightforward fq join
is executed in 50ms, similarly a Boolean combination. Adding in weights using
bf roughly doubles the QTime. I expect in many real world situations the time
taken to call out to the external source would dominate.
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
SOLR-7341.patch, SOLR-7341.patch-trunk
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch-trunk
Patch against trunk (svn rev 1689652)
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
SOLR-7341.patch, SOLR-7341.patch-trunk
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch
Minor bug fixes
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch,
SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch
Latest patch (against 4.10.3) with support for grouping
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a comma-separated list of attributes from the
[jira] [Comment Edited] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610240#comment-14610240
]
Tom Winch edited comment on SOLR-7341 at 7/1/15 1:34 PM:
-
Lastest patch (against 4.10.3) with support for grouping
was (Author: tomjon):
Support for grouping
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch
Support for grouping
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation
[jira] [Comment Edited] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610240#comment-14610240
]
Tom Winch edited comment on SOLR-7341 at 7/1/15 1:34 PM:
-
Latest patch (against 4.10.3) with support for grouping
was (Author: tomjon):
Lastest patch (against 4.10.3) with support for grouping
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch, SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: (was: SOLR-7341.patch)
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search
[jira] [Issue Comment Deleted] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Comment: was deleted
(was: Latest patch (against 4.10.3) with support for grouping)
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Description:
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent,
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory
and XJoinResults, which are implemented by the user to provide the link between
SOLR and the external results source. External results and SOLR documents are
matched via a single configurable attribute (the join field). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar /
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute values
for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
There is one XJoin search component per external source, and each has two main
responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
requestHandler name=/xjoin class=solr.SearchHandler startup=lazy
lst name=defaults
..
bool name=xjoin_testtrue/bool
str name=xjoin_test.listParameterxx/str
str name=xjoin_test.resultstest_count/str
str name=xjoin_test.flid,value/str
/lst
arr name=first-components
strxjoin_test/str
/arr
arr
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Description:
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent,
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory
and XJoinResults, which are implemented by the user to provide the link between
SOLR and the external results source. External results and SOLR documents are
matched via a single configurable attribute (the join field). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar /
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute values
for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
There is one XJoin search component per external source, and each has two main
responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
requestHandler name=/xjoin class=solr.SearchHandler startup=lazy
lst name=defaults
..
bool name=xjoin_testtrue/bool
str name=xjoin_test.listParameterxx/str
str name=xjoin_test.resultstest_count/str
str name=xjoin_test.flid,value/str
/lst
arr name=first-components
strxjoin_test/str
/arr
arr
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Description:
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent,
XJoinValueSourceParser and XJoinQParserPlugin (and associated classes), which
must be configured in solrconfig.xml, and the interfaces XJoinResultsFactory
and XJoinResults, which are implemented by the user to provide the link between
SOLR and the external results source. External results and SOLR documents are
matched via a single configurable attribute (the join field). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar /
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute values
for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
There is one XJoin search component per external source, and each has two main
responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
requestHandler name=/xjoin class=solr.SearchHandler startup=lazy
lst name=defaults
..
bool name=xjoin_testtrue/bool
str name=xjoin_test.listParameterxx/str
str name=xjoin_test.resultstest_count/str
str name=xjoin_test.flid,value/str
/lst
arr name=first-components
strxjoin_test/str
/arr
arr
[jira] [Commented] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530847#comment-14530847
]
Tom Winch commented on SOLR-7341:
-
Added updated patch with more support for multiple external sources
(XJoinQParserPlugin)
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch, SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to
[jira] [Issue Comment Deleted] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Comment: was deleted
(was: You need to create the directory solr/contrib/xjoin/test-lib by hand, and
copy the following JAR files from the directory
solr/contrib/morphlines-core/test-lib:
jcl-over-slf4j-1.7.6.jarmockito-core-1.9.5.jar
objenesis-1.2.jar)
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent, XJoinValueSourceParser and XJoinQParserPlugin (and
associated classes), which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source.
External results and SOLR documents are matched via a single configurable
attribute (the join field). The contrib JAR solr-xjoin-4.10.3.jar contains
these classes and interfaces and should be included in SOLR's class path from
solrconfig.xml, as should a JAR containing the user implementations of the
previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to an
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL
to pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. There is one XJoin search component per external source, and each
has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Attachment: SOLR-7341.patch
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent and XJoinValueSourceParser, which must be configured in
solrconfig.xml, and the interfaces XJoinResultsFactory and XJoinResults,
which are implemented by the user to provide the link between SOLR and the
external results source. External results and SOLR documents are matched via
a single configurable attribute (the join field). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to
the external source to perform a query (or otherwise collect results).
Parameters with prefix component name.external. are passed from the SOLR
query URL to pararameterise the search. The interface has the following
methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. It has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained
in an
[jira] [Commented] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485249#comment-14485249
]
Tom Winch commented on SOLR-7341:
-
Attached 8/4/15
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent and XJoinValueSourceParser, which must be configured in
solrconfig.xml, and the interfaces XJoinResultsFactory and XJoinResults,
which are implemented by the user to provide the link between SOLR and the
external results source. External results and SOLR documents are matched via
a single configurable attribute (the join field). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to
the external source to perform a query (or otherwise collect results).
Parameters with prefix component name.external. are passed from the SOLR
query URL to pararameterise the search. The interface has the following
methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. It has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from
[jira] [Commented] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485264#comment-14485264
]
Tom Winch commented on SOLR-7341:
-
You need to create the directory solr/contrib/xjoin/test-lib by hand, and copy
the following JAR files from the directory
solr/contrib/morphlines-core/test-lib:
jcl-over-slf4j-1.7.6.jarmockito-core-1.9.5.jar
objenesis-1.2.jar
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
Attachments: SOLR-7341.patch
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent and XJoinValueSourceParser, which must be configured in
solrconfig.xml, and the interfaces XJoinResultsFactory and XJoinResults,
which are implemented by the user to provide the link between SOLR and the
external results source. External results and SOLR documents are matched via
a single configurable attribute (the join field). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to
the external source to perform a query (or otherwise collect results).
Parameters with prefix component name.external. are passed from the SOLR
query URL to pararameterise the search. The interface has the following
methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. It has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query
[jira] [Commented] (SOLR-4787) Join Contrib
[
https://issues.apache.org/jira/browse/SOLR-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485282#comment-14485282
]
Tom Winch commented on SOLR-4787:
-
See also the new external source join, xjoin, at
https://issues.apache.org/jira/browse/SOLR-7341
Join Contrib
Key: SOLR-4787
URL: https://issues.apache.org/jira/browse/SOLR-4787
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.2.1
Reporter: Joel Bernstein
Priority: Minor
Fix For: Trunk
Attachments: SOLR-4787-deadlock-fix.patch,
SOLR-4787-pjoin-long-keys.patch, SOLR-4787-with-testcase-fix.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4787.patch, SOLR-4787.patch,
SOLR-4797-hjoin-multivaluekeys-nestedJoins.patch,
SOLR-4797-hjoin-multivaluekeys-trunk.patch
This contrib provides a place where different join implementations can be
contributed to Solr. This contrib currently includes 3 join implementations.
The initial patch was generated from the Solr 4.3 tag. Because of changes in
the FieldCache API this patch will only build with Solr 4.2 or above.
*HashSetJoinQParserPlugin aka hjoin*
The hjoin provides a join implementation that filters results in one core
based on the results of a search in another core. This is similar in
functionality to the JoinQParserPlugin but the implementation differs in a
couple of important ways.
The first way is that the hjoin is designed to work with int and long join
keys only. So, in order to use hjoin, int or long join keys must be included
in both the to and from core.
The second difference is that the hjoin builds memory structures that are
used to quickly connect the join keys. So, the hjoin will need more memory
then the JoinQParserPlugin to perform the join.
The main advantage of the hjoin is that it can scale to join millions of keys
between cores and provide sub-second response time. The hjoin should work
well with up to two million results from the fromIndex and tens of millions
of results from the main query.
The hjoin supports the following features:
1) Both lucene query and PostFilter implementations. A *cost* 99 will
turn on the PostFilter. The PostFilter will typically outperform the Lucene
query when the main query results have been narrowed down.
2) With the lucene query implementation there is an option to build the
filter with threads. This can greatly improve the performance of the query if
the main query index is very large. The threads parameter turns on
threading. For example *threads=6* will use 6 threads to build the filter.
This will setup a fixed threadpool with six threads to handle all hjoin
requests. Once the threadpool is created the hjoin will always use it to
build the filter. Threading does not come into play with the PostFilter.
3) The *size* local parameter can be used to set the initial size of the
hashset used to perform the join. If this is set above the number of results
from the fromIndex then the you can avoid hashset resizing which improves
performance.
4) Nested filter queries. The local parameter fq can be used to nest a
filter query within the join. The nested fq will filter the results of the
join query. This can point to another join to support nested joins.
5) Full caching support for the lucene query implementation. The filterCache
and queryResultCache should work properly even with deep nesting of joins.
Only the queryResultCache comes into play with the PostFilter implementation
because PostFilters are not cacheable in the filterCache.
The syntax of the hjoin is similar to the JoinQParserPlugin except that the
plugin is referenced by the string hjoin rather then join.
fq=\{!hjoin fromIndex=collection2 from=id_i to=id_i threads=6
fq=$qq\}user:customer1qq=group:5
The example filter query above will search the fromIndex (collection2) for
user:customer1 applying the local fq parameter to filter the results. The
lucene filter query will be built using 6 threads. This query will generate a
list of values from the from field that will be used to filter the main
query. Only records from the main query, where the to field is present in
the from list will be included in the results.
The solrconfig.xml in the main query core must contain the reference to the
hjoin.
queryParser name=hjoin
class=org.apache.solr.joins.HashSetJoinQParserPlugin/
And the join contrib lib jars must be registed in the solrconfig.xml.
lib dir=../../../contrib/joins/lib regex=.*\.jar /
After issuing the ant dist command from inside the solr directory the joins
contrib jar will appear in
[jira] [Commented] (SOLR-6568) Join Discovery Contrib
[ https://issues.apache.org/jira/browse/SOLR-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485281#comment-14485281 ] Tom Winch commented on SOLR-6568: - See also the new external source join, xjoin, at https://issues.apache.org/jira/browse/SOLR-7341 Join Discovery Contrib -- Key: SOLR-6568 URL: https://issues.apache.org/jira/browse/SOLR-6568 Project: Solr Issue Type: New Feature Reporter: Joel Bernstein Assignee: Joel Bernstein Priority: Minor Fix For: 5.0 This contribution was commissioned by the *NCBI* (National Center for Biotechnology Information). The Join Discovery Contrib is a set of Solr plugins that support large scale joins and join facets between Solr cores. There are two different Join implementations included in this contribution. Both implementations are designed to work with integer join keys. It is very common in large BioInformatic and Genomic databases to use integer primary and foreign keys. Integer keys allow Bioinformatic and Genomic search engines and discovery tools to perform complex operations on large data sets very efficiently. The Join Discovery Contrib provides features that will be applicable to anyone working with the freely available databases from the NCBI and likely a large number of other BioInformatic and Genomic databases. These features are not specific though to Bioinformatics and Genomics, they can be used in any datasets where integer keys are used to define the primary and foreign keys. What is included in this contrib: 1) A new JoinComponent. This component is used instead of the standard QueryComponent. It facilitates very large scale relational joins between two Solr indexes (cores). The join algorithm used in this component is known as a *parallel partitioned merge join*. This is an algorithm which partitions the results from both sides of the join and then sorts and merges the partitions in parallel. Below are some of it's features: * Sub-second performance on very large joins. The parallel join algorithm is capable of sub-second performance on joins with tens of millions of records on both sides of the join. * The JoinComponent returns tuples with fields from both sides of the join. The initial release returns the primary keys from both sides of the join and the join key. * The tuples also include, and are ranked by, a combined score from both sides of the join. * Special purpose memory-mapped on-disk indexes to support \*:\* joins. This makes it possible to join an entire index with a sub-set of another index with sub-second performance. * Support for very fast one-to-one, one-to-many and many-to-many joins. Fast many-to-many joins make it possible to join between indexes on multi-value fields. 2) A new JoinFacetComponent. This component provides facets for both indexes involved in the join. 3) The BitSetJoinQParserPlugin. A very fast parallel filter join based on bitsets that supports infinite levels of nesting. It can be used as a filter query in combination with the JoinComponent or with the standard query component. -- 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] [Created] (SOLR-7341) xjoin - join data from external sources
Tom Winch created SOLR-7341:
---
Summary: xjoin - join data from external sources
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent and
XJoinValueSourceParser, which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source. External
results and SOLR documents are matched via a single configurable attribute (the
join field). The contrib JAR solr-xjoin-4.10.3.jar contains these classes and
interfaces and should be included in SOLR's class path from solrconfig.xml, as
should a JAR containing the user implementations of the previously mentioned
interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar /
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to the
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute values
for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
It has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* listParameter - external join field values will be placed in this query
parameter for reference by local query parameters
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
requestHandler name=/xjoin class=solr.SearchHandler startup=lazy
lst
[jira] [Updated] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Winch updated SOLR-7341:
Description:
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR results
in a query and the SOLR result set to be filtered by the results of an external
query. Values from the external results are made available in the SOLR results
and may also be used to boost the scores of corresponding documents during the
search. The contrib consists of the Java classes XJoinSearchComponent and
XJoinValueSourceParser, which must be configured in solrconfig.xml, and the
interfaces XJoinResultsFactory and XJoinResults, which are implemented by the
user to provide the link between SOLR and the external results source. External
results and SOLR documents are matched via a single configurable attribute (the
join field). The contrib JAR solr-xjoin-4.10.3.jar contains these classes and
interfaces and should be included in SOLR's class path from solrconfig.xml, as
should a JAR containing the user implementations of the previously mentioned
interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar /
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to the
external source to perform a query (or otherwise collect results). Parameters
with prefix component name.external. are passed from the SOLR query URL to
pararameterise the search. The interface has the following methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults() method
of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute values
for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request handlers.
It has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the XJoinResultsFactory
implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure it.
To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured with
the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained in
an XJoinResults implementation) to be included in the SOLR results
For example:
{code:xml}
requestHandler name=/xjoin class=solr.SearchHandler startup=lazy
lst name=defaults
..
bool name=xjoin_testtrue/bool
str name=xjoin_test.listParameterxx/str
str name=xjoin_test.resultstest_count/str
str name=xjoin_test.flid,value/str
/lst
arr name=first-components
strxjoin_test/str
/arr
arr name=last-components
strxjoin_test/str
/arr
/requestHandler
{code}
h3. XJoinQParserPlugin
This query
[jira] [Commented] (SOLR-7341) xjoin - join data from external sources
[
https://issues.apache.org/jira/browse/SOLR-7341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392905#comment-14392905
]
Tom Winch commented on SOLR-7341:
-
Patch file on the way.
xjoin - join data from external sources
---
Key: SOLR-7341
URL: https://issues.apache.org/jira/browse/SOLR-7341
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.10.3
Reporter: Tom Winch
Priority: Minor
Fix For: Trunk
h2. XJoin
The xjoin SOLR contrib allows external results to be joined with SOLR
results in a query and the SOLR result set to be filtered by the results of
an external query. Values from the external results are made available in the
SOLR results and may also be used to boost the scores of corresponding
documents during the search. The contrib consists of the Java classes
XJoinSearchComponent and XJoinValueSourceParser, which must be configured in
solrconfig.xml, and the interfaces XJoinResultsFactory and XJoinResults,
which are implemented by the user to provide the link between SOLR and the
external results source. External results and SOLR documents are matched via
a single configurable attribute (the join field). The contrib JAR
solr-xjoin-4.10.3.jar contains these classes and interfaces and should be
included in SOLR's class path from solrconfig.xml, as should a JAR containing
the user implementations of the previously mentioned interfaces. For example:
{code:xml}
config
..
!-- XJoin contrib JAR file --
lib dir=${solr.install.dir:../../..}/dist/ regex=solr-xjoin-\d.*\.jar
/
..
!-- user implementations of XJoin interfaces --
lib path=/path/to/xjoin_test.jar /
..
/config
{code}
h2. Java classes and interfaces
h3. XJoinResultsFactory
The user implementation of this interface is responsible for connecting to
the external source to perform a query (or otherwise collect results).
Parameters with prefix component name.external. are passed from the SOLR
query URL to pararameterise the search. The interface has the following
methods:
* void init(NamedList args) - this is called during SOLR initialisation, and
passed parameters from the search component configuration (see below)
* XJoinResults getResults(SolrParams params) - this is called during a SOLR
search to generate external results, and is passed parameters from the SOLR
query URL (as above)
For example, the implementation might perform queries of an external source
based on the 'q' SOLR query URL parameter (in full, component
name.external.q).
h3. XJoinResults
A user implementation of this interface is returned by the getResults()
method of the XJoinResultsFactory implementation. It has methods:
* Object getResult(String joinId) - this should return a particular result
given the value of the join attribute
* IterableString getJoinIds() - this should return the join attribute
values for all results of the external search
h3. XJoinSearchComponent
This is the central Java class of the contrib. It is a SOLR search component,
configured in solrconfig.xml and included in one or more SOLR request
handlers. It has two main responsibilities:
* Before the SOLR search, it connects to the external source and retrieves
results, storing them in the SOLR request context
* After the SOLR search, it matches SOLR document in the results set and
external results via the join field, adding attributes from the external
results to documents in the SOLR results set
It takes the following initialisation parameters:
* factoryClass - this specifies the user-supplied class implementing
XJoinResultsFactory, used to generate external results
* joinField - this specifies the attribute on which to join between SOLR
documents and external results
* external - this parameter set is passed to configure the
XJoinResultsFactory implementation
For example, in solrconfig.xml:
{code:xml}
searchComponent name=xjoin_test
class=org.apache.solr.search.xjoin.XJoinSearchComponent
str name=factoryClasstest.TestXJoinResultsFactory/str
str name=joinFieldid/str
lst name=external
str name=values1,2,3/str
/lst
/searchComponent
{code}
Here, the search component instantiates a new TextXJoinResultsFactory during
initialisation, and passes it the values parameter (1, 2, 3) to configure
it. To properly use the XJoinSearchComponent in a request handler, it must be
included at the start and end of the component list, and may be configured
with the following query parameters:
* results - a comma-separated list of attributes from the XJoinResults
implementation (created by the factory at search time) to be included in the
SOLR results
* fl - a comma-separated list of attributes from results objects (contained
in an
[jira] [Commented] (SOLR-1387) Add more search options for filtering field facets.
[ https://issues.apache.org/jira/browse/SOLR-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14381919#comment-14381919 ] Tom Winch commented on SOLR-1387: - Thanks Alan! Add more search options for filtering field facets. --- Key: SOLR-1387 URL: https://issues.apache.org/jira/browse/SOLR-1387 Project: Solr Issue Type: New Feature Components: search Reporter: Anil Khadka Assignee: Alan Woodward Fix For: Trunk, 5.1 Attachments: SOLR-1387.patch Currently for filtering the facets, we have to use prefix (which use String.startsWith() in java). We can add some parameters like * facet.iPrefix : this would act like case-insensitive search. (or --- facet.prefix=afacet.caseinsense=on) * facet.regex : this is pure regular expression search (which obviously would be expensive if issued). Moreover, allowing multiple filtering for same field would be great like facet.prefix=a OR facet.prefix=A ... sth like this. All above concepts could be equally applicable to TermsComponent. -- 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-1387) Add more search options for filtering field facets.
[ https://issues.apache.org/jira/browse/SOLR-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216072#comment-14216072 ] Tom Winch commented on SOLR-1387: - As the name suggests, CharacterUtils works on a char[] whereas we have a BytesRef (essentially a byte[]). But I think CharacterUtils.toLowerCase() is doing essentially the same as I'm doing in StringHelper.contains() in that it converts using Unicode case mapping information (via Character.toLowerCase(int)). Yes, sadly making ignoreCase more general would spoil the efficiency of facet.prefix so I thought safest to leave as a sub-parameter of facet.contains, which spoils that efficiency already. Add more search options for filtering field facets. --- Key: SOLR-1387 URL: https://issues.apache.org/jira/browse/SOLR-1387 Project: Solr Issue Type: New Feature Components: search Reporter: Anil Khadka Assignee: Alan Woodward Fix For: 4.9, Trunk Attachments: SOLR-1387.patch Currently for filtering the facets, we have to use prefix (which use String.startsWith() in java). We can add some parameters like * facet.iPrefix : this would act like case-insensitive search. (or --- facet.prefix=afacet.caseinsense=on) * facet.regex : this is pure regular expression search (which obviously would be expensive if issued). Moreover, allowing multiple filtering for same field would be great like facet.prefix=a OR facet.prefix=A ... sth like this. All above concepts could be equally applicable to TermsComponent. -- 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-1387) Add more search options for filtering field facets.
[ https://issues.apache.org/jira/browse/SOLR-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Winch updated SOLR-1387: Attachment: SOLR-1387.patch I've been looking at this issue from the use-case of autocompletion, and in this case it's very desirable to include completions from the middle of a word. I've developed a patch which adds the following faceting parameters: facet.contains - similar to facet.prefix, but the string supplied may appear anywhere in the term facet.contains.ignoreCase - a Boolean value; if true, the comparison is case insensitive The implementation for facet.contains has been done for the enum, fc, fcs and grouped faceting methods. The memory usage and performance is likely to be as 'bad' as for the same query without the facet.contains restriction (you lose the advantage of sorted values that can be leveraged in facet.prefix). The ignore-case is implemented in terms of UTF-8 case insensitivity so is also potentially computationally expensive. Add more search options for filtering field facets. --- Key: SOLR-1387 URL: https://issues.apache.org/jira/browse/SOLR-1387 Project: Solr Issue Type: New Feature Components: search Reporter: Anil Khadka Fix For: 4.9, Trunk Attachments: SOLR-1387.patch Currently for filtering the facets, we have to use prefix (which use String.startsWith() in java). We can add some parameters like * facet.iPrefix : this would act like case-insensitive search. (or --- facet.prefix=afacet.caseinsense=on) * facet.regex : this is pure regular expression search (which obviously would be expensive if issued). Moreover, allowing multiple filtering for same field would be great like facet.prefix=a OR facet.prefix=A ... sth like this. All above concepts could be equally applicable to TermsComponent. -- 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
