[
https://issues.apache.org/jira/browse/ACCUMULO-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383137#comment-15383137
]
Josh Elser commented on ACCUMULO-4376:
--------------------------------------
bq. I like this idea, and it was something I was thinking about doing for the
2.0.0 API changes. It might be best if we coordinate this a bit, and decide
what the next version of Accumulo will be, with these changes. I'd hate to add
them in the old API, only to provide replacements in 2.0.
It sounds like you haven't actually done anything yet for the 2.0 API re-write
you've been working on. Why would we have to have replacements for it in 2.0?
How would we future proof something that doesn't exist yet? :)
I just don't want this to get bogged down in 2.0 hypotheticals. If there are
concrete things we can do to make sure this will fit well into your redesign,
please do share that info.
> 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: 1.9.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)
