[
https://issues.apache.org/jira/browse/SOLR-16595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688667#comment-17688667
]
ASF subversion and git services commented on SOLR-16595:
--------------------------------------------------------
Commit f40b35c3d9ff7e6f4dd314d8fce64ceee2604952 in solr's branch
refs/heads/branch_9x from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=f40b35c3d9f ]
SOLR-16595: Standardize Solr Client Builders handling of times (#1338)
* Introducing TimeUnit into Builder methods to allow callers to determine time
unit.
* Internally name each property with what unit of measurement to use, and
convert to that in the Builder.
> Standardize Builder handling of times
> -------------------------------------
>
> Key: SOLR-16595
> URL: https://issues.apache.org/jira/browse/SOLR-16595
> Project: Solr
> Issue Type: Sub-task
> Components: clients - java
> Affects Versions: 9.0
> Reporter: Eric Pugh
> Assignee: Eric Pugh
> Priority: Major
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> COming out of another ticket:
> TimeUnit class was introduced in part to add clarity to call-sites of a
> method so the unit is clear. blah.setTime(TimeUnit.SECOND, 1) is fine as well
> as blah.setTime(TimeUnit.MINUTE,2) -- the caller picks the unit convenient to
> them. With that design, the method is designed unit-free -- definitely NOT
> with variables named "second" as you proposed since the unit could be
> anything. Internally (implementation of the setter), we need to pick a unit
> to standardize to on some internal field to store the result, and name the
> field to be clear as to what the internal unit chosen is. (e.g.
> retryExpirySecs). Again, that's internal, the caller choses a unit convenient
> to them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
