lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-7151) SolrClient.query() methods should throw IOException
Date Tue, 24 Feb 2015 13:59:04 GMT

    [ https://issues.apache.org/jira/browse/SOLR-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14334881#comment-14334881
] 

Shawn Heisey edited comment on SOLR-7151 at 2/24/15 1:58 PM:
-------------------------------------------------------------

bq. I'm not sure if this should go into 5.x as well as trunk, as it's a backwards-breaking
change. I'm leaning towards yes, as it's a sufficiently useful API change that it's worth
the break, but I'm not going to insist on it.

+1 to 5x.  I have no idea whether I'm in the minority here.  I fully expect that anytime I
update a library (like SolrJ) that my program uses, I may need to fix my code, and at the
very least I will need to recompile my programs.  If the change is documented in whatever
the package has for a CHANGES file, that's even better.

So far I've been extraordinarily lucky in that I've only needed to make changes to take advantage
of new features, the code has always compiled successfully on SolrJ updates.  It's a bonus
that I did not expect; I'm OK with minor changes in the API.  Large scale refactorings in
a minor version update might bother me, but only if they do not come with a major advancement
in the library's usability or capability.

To put it another way: If CHANGES.txt informs me that I may not be able to do a drop-in jar
replacement with that minor update, that's enough notice for me ... although I would have
assumed that anyway.


was (Author: elyograg):
bq. I'm not sure if this should go into 5.x as well as trunk, as it's a backwards-breaking
change. I'm leaning towards yes, as it's a sufficiently useful API change that it's worth
the break, but I'm not going to insist on it.

+1 to 5x.  I have no idea whether I'm in the minority here.  I fully expect that anytime I
update a library (like SolrJ) that my program uses, I may need to fix my code, and at the
very least I will need to recompile my programs.  If the change is documented in whatever
the package has for a CHANGES file, that's even better.

So far I've been extraordinarily lucky in that I've only needed to make changes to take advantage
of new features, the code has always compiled successfully on SolrJ updates.  It's a bonus
that I did not expect; I'm OK with minor changes in the API.  Large scale refactorings in
a minor version update might bother me, but only if they do not come with a major advancement
in the library's usability or capability.


> SolrClient.query() methods should throw IOException
> ---------------------------------------------------
>
>                 Key: SOLR-7151
>                 URL: https://issues.apache.org/jira/browse/SOLR-7151
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrJ
>            Reporter: Alan Woodward
>            Assignee: Alan Woodward
>            Priority: Minor
>             Fix For: Trunk, 5.1
>
>         Attachments: SOLR-7151.patch
>
>
> All the methods on SolrClient are declared as throwing SolrServerException (thrown if
there's an error somewhere on the server), and IOException (thrown if there's a communication
error), except for the QueryRequest methods.  These swallow up IOException and repackage them
in a SolrServerException.
> I think these are useful distinctions to make (you might want to retry on an IOException,
but not on a SolrServerException), and we should make the query methods fall in line with
the others.
> I'm not sure if this should go into 5.x as well as trunk, as it's a backwards-breaking
change.  I'm leaning towards yes, as it's a sufficiently useful API change that it's worth
the break, but I'm not going to insist on it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message