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

David Smiley commented on SOLR-14596:
-------------------------------------

I think you care about this more than me.  Just go for it.  But I still cling 
to the belief that it's acceptable and reasonable to throw UOE if we don't want 
the LOC (lines of code) hanging around for a dubious use-case.  It advertises 
to the user explicitly that it is not only not supported, but probably doesn't 
make sense either.  And I don't think it makes sense for this request hierarchy 
in particular.

You make a good point that forgetting some fields on a hashCode isn't a big 
problem (particularly for dubious/non-existent use-cases) where it would be for 
equals (which I'm not objecting to).

> Add equals()/hashCode() impls to SolrJ Request objects
> ------------------------------------------------------
>
>                 Key: SOLR-14596
>                 URL: https://issues.apache.org/jira/browse/SOLR-14596
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrJ
>    Affects Versions: master (9.0), 8.5.2
>            Reporter: Jason Gerlowski
>            Priority: Minor
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> Currently, many SolrRequest classes (e.g. UpdateRequest) don't implement 
> {{equals()}} or {{hashCode()}}
> This isn't a problem for Solr's normal operation, but it can be a barrier in 
> unit testing SolrJ client code.  {{equals()}} implementations would make it 
> much easier to assert that client code is building the request that 
> developers _think_ it's building.  Of course, this testing benefit would 
> apply to Solr's own tests which use SolrJ.
> This ticket covers making sure that the more popular SolrRequest objects have 
> equals/hashcode implementations useful for testers.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to