[
https://issues.apache.org/jira/browse/ACCUMULO-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684218#comment-13684218
]
Adam Fuchs commented on ACCUMULO-1488:
--------------------------------------
I think we are all in agreement that consensus seeking is a good thing. The
issue at hand is whether to include this feature in the 1.5 branch, not whether
we should have debates. My comment about the effort spent on this argument is
simply meant to imply that the benefit of second guessing this particular
action of mine as a committer is negligible compared to the time we are wasting
on this particular debate. Perhaps I jumped to a conclusion too soon, and so I
am happy to include a more thorough justification of why I think this feature
should be included:
1. This feature is a modular addition. There are no dependencies on it anywhere
else in the Accumulo code base, and it only depends on an interface that has
been stable over the course of several releases. Maintenance of this feature
will include bug fixes limited to the module and adaptation to changes in the
underlying interfaces. In the 1.5 branch, the latter will not happen, so we're
only talking about bug fixes to the module itself. I don't think anyone is
arguing that bug fixes of this module are going to be challenging in 1.5, nor
are they a reason to roll back to an earlier version.
2. There is concern about the addition to the API that this feature brings, and
whether that will change before 1.6 is released. To that point, I would argue
that there is always the option of supporting multiple sets of user iterators,
and the additional cost of having this feature in perpetuity alongside whatever
other set of iterators that subsume this functionality will be an upper bound
on the marginal effort incurred by this change. That is in part due to the fact
that we have several other examples of code that use the same interfaces on
which this feature depends, so it does not introduce additional maintenance
beyond the module itself. We can amortize the cost of maintaining this module
by roughly comparing it to the benefit to our user base. I would say that if
one project takes advantage of it that more than makes up for the perpetual
maintenance cost of the module, but we can debate that if you like. Let me also
note that I did post this feature as a patch for a week before committing it,
and there is still plenty of time to change the API before 1.5.1 is released if
we want to do so.
3. An additional point that has been made is that there are alternative
solutions. In fact, this feature could be included into an instance of Accumulo
1.5 as a jar included in the lib/ext directory. This approach is quite easy for
anyone that knows how to compile java code into jars, has write access to the
lib/ext directory on the instance they want to use, and doesn't have any other
security policies to go through before including code outside of the core
Accumulo code base. Users that do not fit that category will have other hoops
to jump through, and we have seen many instances of such users. Even for the
users in the "easy" category, this is a cost incurred per instance of Accumulo
which is generally higher than the cost of including it in the primary build.
4. There is also a discussion of the cost of waiting to 1.6 for this feature to
be included. We can probably estimate that this will be 2 months at a minimum,
which admittedly is not very long. However, there is some uncertainly around
that cost which is mitigated by back-porting to the 1.5 branch. That mitigation
is really the only benefit of back-porting, and obviously must be weighed
against the costs. Including a long debate in the costs obviously reduces the
number of features we would choose to backport, so I think it's important that
we trust our committers to make such a decision and delegate that
responsibility.
> support BigDecimal encoding for basic built-in combiners
> --------------------------------------------------------
>
> Key: ACCUMULO-1488
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1488
> Project: Accumulo
> Issue Type: New Feature
> Reporter: Adam Fuchs
> Fix For: 1.5.1, 1.6.0
>
> Attachments: ACCUMULO-1488.patch
>
>
> Support sum, min, and max operations for decimal numbers using the
> java.math.BigDecimal String encoding and decoding functions
> (BigDecimal.toString() and BigDecimal(String)).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
