accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Havanki (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1958) Range constructor lacks key checks, should be non-public
Date Thu, 05 Dec 2013 18:59:35 GMT

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

Bill Havanki commented on ACCUMULO-1958:
----------------------------------------

I'd be OK with leaving out the range check in 1.6.0 as long as the method is deprecated, since
that's a flag to users that it's dangerous, and users will likely need to make code changes
for 1.6.0 and can take the opportunity to move away from it.

For 1.4.x and 1.5.x, though, I think we'd need to add the range check. Even if we deprecate
it there too, users won't be expected to rebuild moving from 1.x.y to 1.x.(y+1), so they'll
continue using the constructor. In that case, it's tantamount to a bug fix.

I'm unsure, since I don't know fully the compatibility promises and standards for Accumulo
across versions.

> Range constructor lacks key checks, should be non-public
> --------------------------------------------------------
>
>                 Key: ACCUMULO-1958
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1958
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.4.0
>            Reporter: Bill Havanki
>             Fix For: 1.7.0
>
>
> This ticket pertains to the Range class constructor with the following signature:
> {noformat}
> public Range(Key, Key, boolean, boolean, boolean, boolean)
> {noformat}
> The constructor does not check that the start key is before the end key, like every other
constructor in the class. Since the constructor is public, this makes it possible for a caller
to create invalid ranges.
> The constructor is used by other constructors that take in existing range objects, where
the key check has implicitly been done, and so it would make sense to skip the check in this
one, but then the constructor visibility should be at least protected.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message