accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mario Pastorelli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4376) Introduce a Builders for "data" classes
Date Sun, 28 Aug 2016 09:13:22 GMT

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

Mario Pastorelli commented on ACCUMULO-4376:
--------------------------------------------

Well [~ctubbsii], that's disappointing. You do have implemented this in ACCUMULO-2589 even
if there is nothing pointing to this JIRA or anything related in ACCUMULO-2589. [~elserj]
I guess we can close this as duplicate to avoid wasting other developers time.

[~ctubbsii] [~dlmarion] I don't wish to get started for the simple reason that if I use a
huge branch like ACCUMULO-2589 as starting point, I would have to lookup every single related
change over 342 files changed from 1.8 (4.665 lines added, 10.137 lines deleted where most
of the commits messages are "Merge branch '1.8'", github gives up in showing the changes),
understand if they are related to this JIRA, understand why and what has been changed from
the current design, and then maybe implement this again. In the meanwhile everything has been
already implemented and I don't like pointless exercises.
Besides, I miss where all those important design decisions have been taken and I don't understand
why there are JIRAs desynchronized with the work in that branch.

[~elserj] let me know if I can help with something else.

> Introduce a Builders for "data" classes
> ---------------------------------------
>
>                 Key: ACCUMULO-4376
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4376
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>            Reporter: Josh Elser
>             Fix For: 2.0.0
>
>
> In looking at ACCUMULO-4375, I was a little frustrated at how we have 3x constructors
than Key really provides just to support {{byte[]}}, {{Text}}, and {{CharSequence}} arguments.
Additionally, the {{copy}} argument forces the user to use the most specific (most arguments)
constructor if they want to avoid the copy. This makes constructing a Key from just a row
while avoiding a copy very pedantic.
> I think a KeyBuilder (or KeyFactory) class would be a big usability benefit and reduce
the amount of code that clients have to write to most efficiently construct Keys.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message