[
https://issues.apache.org/jira/browse/BEAM-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16468513#comment-16468513
]
Tim Robertson edited comment on BEAM-3947 at 5/9/18 7:45 AM:
-------------------------------------------------------------
I've given this a little more thought. I presume we could scope {{solr-solrj}}
as {{provided}} but compile the {{SolrIO}} against version 5.x (or whatever
makes sense) and document in the IO readme that it is known to run with
versions 5,6,7. Note that the [HCatalogIO does
this|https://github.com/apache/beam/blob/master/sdks/java/io/hcatalog/pom.xml#L224],
so there is precedent but [it is not without issue
(BEAM-4260)|https://issues.apache.org/jira/browse/BEAM-4260]. In the tests, we
could follow the elasticsearch approach with a module per version, knowing that
it will then use the same {{solrj}} as the running server. The 5,6,7 tests will
verify that this is known to work with any of the provided versions.
This just kicks the can down the road though; when we do start bringing in the
column oriented features for performance we have to assume we will be using non
compatible {{solrj}} methods at some point and then we'd be forced to have
different {{SolrIO}} versions for each server.
Perhaps knowing this is enough that we should structure the project now to
support that? (As a Beam / Solr user, I'm keen to help out if it is of use)
was (Author: timrobertson100):
I've given this a little more thought. I presume we could scope {{solr-solrj}}
as {{provided}} but compile the {{SolrIO}} against version 5.x (or whatever
makes sense) and document in the IO readme that it is known to run with
versions 5,6,7. Note that the [HCatalogIO does
this|https://github.com/apache/beam/blob/master/sdks/java/io/hcatalog/pom.xml#L224],
so there is precedent but [it is not without issue
(BEAM-4260)|https://issues.apache.org/jira/browse/BEAM-4260]. In the tests, we
could follow the elasticsearch approach with a module per version, knowing that
it will then use the same {{solrj}} as the running server. The 5,6,7 tests will
verify that this is known to work with any of the provided versions.
This just kicks the can down the road though; when we do start bringing in the
column oriented features for performance we have to assume we will be using non
compatible {{solrj}} methods at some point and then we'd be forced to have
different {{SolrIO}} versions for each server.
Perhaps knowing this is enough that we should structure the project now to
support that?
> Add support for Solr 6.x/7.x
> ----------------------------
>
> Key: BEAM-3947
> URL: https://issues.apache.org/jira/browse/BEAM-3947
> Project: Beam
> Issue Type: Improvement
> Components: io-java-solr
> Reporter: Ismaël Mejía
> Assignee: Cao Manh Dat
> Priority: Minor
>
> The initial PR on Solr was based on Solr 6.x, however at that time we
> supported Java 7 so Insisted to move it to Solr 5.x (which is Java 7
> compatible). This issue is to add support for multiple versions of Solr
> ideally in a single module.
> Notice that I was able to recover the original code for Solr 6.x created by
> [~caomanhdat] here (there are some differences in the way the Split was
> calculated and maybe some other minor things):(
> [https://github.com/iemejia/beam/blob/recover-solrio/sdks/java/io/solr/pom.xml]
> This issue does not cover support for Solr 7, but if it is possible to add it
> as part of it, it would be great.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
