accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Fuchs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1488) support BigDecimal encoding for basic built-in combiners
Date Sat, 15 Jun 2013 15:04:23 GMT

    [ 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

Mime
View raw message