[
https://issues.apache.org/jira/browse/SOLR-14596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178307#comment-17178307
]
Jason Gerlowski edited comment on SOLR-14596 at 8/15/20, 4:34 PM:
------------------------------------------------------------------
I'd be more sympathetic to avoiding the maintenance burden, but:
# I don't think users should _need_ to ask us to abide by standard Java
"contracts". This is just part of being a well-behaved Java client library.
# It's not a hypothetical problem - you can find examples of this in Solr code
itself. (Here's
[one|https://github.com/apache/lucene-solr/blob/a80eb84d5659a06a10860ad2470e87d80b19fa5d/solr/core/src/test/org/apache/solr/update/MockingHttp2SolrClient.java#L43]
place) There's lots of reasons users might want to do this.
# Not sure if being a committer loses me my "user" voice, but I've run into
HashMap problems myself. That's one of the things that put me over the edge to
actually file and pick this up.
# This is very low-complexity code - you can generate similar implementations
with an IDE. The maintenance burden is non-zero, sure. But I think we can
agree it's pretty small in the scheme of things?
That's about as good of a case as I can make for this. If you're still
unconvinced and feel very strongly about it, I'll work hashCode out of the
patch sometime soon. Lmk.
was (Author: gerlowskija):
I'd be more sympathetic to avoiding the maintenance burden, but:
# I don't think users should _need_ to ask us to abide by standard Java
"contracts". This is just part of being a well-behaved Java client library.
# It's not a hypothetical problem - you can find examples of this in Solr code
itself. (Here's
[one|https://github.com/apache/lucene-solr/blob/a80eb84d5659a06a10860ad2470e87d80b19fa5d/solr/core/src/test/org/apache/solr/update/MockingHttp2SolrClient.java#L43]
place) There's lots of reasons users might want to do this.
# Not sure if being a committer loses me my "user" voice, but I've run into
HashMap problems myself. That's one of the things that put me over the edge to
actually file and pick this up.
# This is very low-complexity code - you can generate similar implementations
with an IDE. The maintenance burden is non-zero, sure. But I think we can
agree it's pretty small in the scheme of things?
> 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: 0.5h
> 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: [email protected]
For additional commands, e-mail: [email protected]
