According to the definition of the public API in version 1.5.0, RangeInputSplit is a part of the public API.
On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser <[email protected]> wrote: > Devil's advocate: RangeInputSplit isn't part of the public API either, so > it comes with the same risks that TabletLocator would. > > It sounds more like the definition of "public api" should be expanded to > prevent this in future cases. I need to look at what exactly broke for Don. > > > On 3/28/14, 9:12 AM, Sean Busbey wrote: > >> Don, >> >> If you can file a jira with some example code that covers what parts of >> the >> 1.5.0 API you hit, I can see if I can a patch to get you working. >> >> That would give you a patch you could apply on top of 1.5.1 now and when >> 1.5.2 comes out it would correctly support the API. >> >> -Sean >> >> On Fri, Mar 28, 2014 at 8:49 AM, Donald Miner <[email protected] >> >wrote: >> >> I'm starting to dig around for a workaround and figured someone might be >>> able to help me right away. >>> >>> In digging deeper, we were using RangeInputSplit because it gave us the >>> splits AND the locations. We use the locations for some data locality >>> placing in our distributed application. listSplits only gives us splits. >>> >>> Is there an easy way to get both of these pieces of information together? >>> >>> >>> On Thu, Mar 27, 2014 at 3:28 PM, Josh Elser <[email protected]> >>> wrote: >>> >>> Ack, sorry about that, Don. >>>> >>>> We probably should have been more strict about that. It's tough to make >>>> a >>>> call about a public class that someone *might* be using. >>>> >>>> >>>> On 3/27/14, 12:26 PM, Donald Miner wrote: >>>> >>>> Sorry to necro this thread, just wanted to throw my 2 cents in. >>>>> >>>>> We had some user code referencing this code directly and our >>>>> application >>>>> no >>>>> longer works in 1.5.1. Just found out today when installing on 1.5.1. >>>>> In >>>>> retrospect, we should have been using .listSplits from TableOperatons, >>>>> >>>> but >>> >>>> instead we were using the RangeInputSplit method to get the splits for a >>>>> table. >>>>> >>>>> I guess since we probably shouldn't have been doing that, I don't know >>>>> >>>> if >>> >>>> that's a case for this not being deleted without going to deprecated... >>>>> but >>>>> we did have a nasty surprise and a deprecation warning would have been >>>>> nice. >>>>> >>>>> -d >>>>> >>>>> >>>>> On Tue, Feb 25, 2014 at 11:33 PM, Adam Fuchs <[email protected]> >>>>> wrote: >>>>> >>>>> I'll buy that the RangeInputSplit is probably not referenced directly >>>>> >>>> in >>> >>>> user code. In this case it's probably not a big enough change to delay >>>>>> the >>>>>> release. >>>>>> >>>>>> Adam >>>>>> On Feb 25, 2014 6:19 PM, "Christopher" <[email protected]> >>>>>> wrote: >>>>>> >>>>>> I don't know that this inner class used for M/R should be considered >>>>>> >>>>>>> public API... nor do I imagine it will cause compatibility problems >>>>>>> if >>>>>>> users aren't referencing it in their code (which there's no reason to >>>>>>> expect them to). I don't know if anybody is subclassing >>>>>>> RangeInputSplit, but I'd suspect that it's an acceptable risk. >>>>>>> Re-adding an inner class that subclasses the now external one may be >>>>>>> a >>>>>>> good workaround. I don't think this would require recompilation for >>>>>>> runtime compatibility, but if it does, I think that's probably >>>>>>> acceptable. >>>>>>> >>>>>>> -- >>>>>>> Christopher L Tubbs II >>>>>>> http://gravatar.com/ctubbsii >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 25, 2014 at 6:13 PM, Josh Elser <[email protected]> >>>>>>> >>>>>>> wrote: >>>>>> >>>>>> I haven't checked what would happen. If you subclassed the >>>>>>> >>>>>>>> >>>>>>>> RangeInputSplit, >>>>>>> >>>>>>> it's rather likely that you'd need a recompilation. >>>>>>>> >>>>>>>> >>>>>>>> On 2/25/14, 5:59 PM, John Vines wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Will it? Clients don't interact with that code at all directly. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Feb 25, 2014 at 5:57 PM, Adam Fuchs <[email protected]> >>>>>>>>> >>>>>>>>> wrote: >>>>>>>> >>>>>>> >>>>>> >>>>>>> Thanks for running that checker, Keith. Should we not be worried >>>>>>>>> >>>>>>>>>> >>>>>>>>>> about >>>>>>>>> >>>>>>>> >>>>>> the >>>>>>> >>>>>>>> removal of InputFormatBase.RangeInputSplit? If I read correctly >>>>>>>>>> >>>>>>>>> this >>> >>>> >>>>>>>>>> will >>>>>>>>> >>>>>>>> >>>>>>> break both binary (runtime) compatibility and code (compile-time) >>>>>>>> >>>>>>>>> compatibility. Can somebody make an argument for why this is not a >>>>>>>>>> problem >>>>>>>>>> in a minor release with no previous deprecation? >>>>>>>>>> >>>>>>>>>> Is there a quick way to fix this, like by subclassing the >>>>>>>>>> org.apache.accumulo.core.client.mapred.RangeInputSplit in a >>>>>>>>>> o.a.a.c.c.mapred.InputFormatBase.RangeInputSplit that we mark as >>>>>>>>>> deprecated? >>>>>>>>>> >>>>>>>>>> Adam >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Feb 25, 2014 at 5:17 PM, Keith Turner <[email protected]> >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> I ran a utility [1] to analyze API diffs [2] between 1.5.0 and >>>>>>>>>> >>>>>>>>>>> 1.5.1-RC3. >>>>>>>>>>> The configs I used are the two xml files in the parent [3] of the >>>>>>>>>>> report. >>>>>>>>>>> I think the diff looks ok. I used jars from 1.5.0 and 1.5.1-RC3 >>>>>>>>>>> bin.tar.gz. >>>>>>>>>>> >>>>>>>>>>> [1] : >>>>>>>>>>> >>>>>>>>>>> http://ispras.linuxbase.org/index.php/Java_API_Compliance_ >>>>>>>>>> Checker >>>>>>>>>> >>>>>>>>> >>>>>>> [2] : >>>>>>>> >>>>>>>>> >>>>>>>>>>> http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/ >>>>>>>>>>> >>>>>>>>>> compat_report.html >>>>>>> >>>>>>> [3] : http://people.apache.org/~kturner/1.5.0_to_1.5.1-RC3/ >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Feb 24, 2014 at 8:01 PM, Josh Elser < >>>>>>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>>> >>>> >>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> All, >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Please consider the following candidate as Apache Accumulo 1.5.1 >>>>>>>>>>>> >>>>>>>>>>> -- >>> >>>> >>>>>>>>>>>> now >>>>>>>>>>> >>>>>>>>>> >>>>>>> with 100% more CHANGES changes. >>>>>>>> >>>>>>>>> >>>>>>>>>>>> Git artifacts: The staging repository was built from the tag >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> "1.5.1-rc3" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> (3478f71a). >>>>>>>>>>>> >>>>>>>>>>>> Maven Staging Repo: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> https://repository.apache.org/content/repositories/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> orgapacheaccumulo-1002 >>>>>>>>>>>> >>>>>>>>>>>> Source tarball: >>>>>>>>>>>> >>>>>>>>>>> http://repository.apache.org/content/repositories/ >>> >>>> orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5. >>>>>>>>>>>> 1/accumulo-1.5.1-src.tar.gz >>>>>>>>>>>> >>>>>>>>>>>> Binary tarball: >>>>>>>>>>>> >>>>>>>>>>> http://repository.apache.org/content/repositories/ >>> >>>> orgapacheaccumulo-1002/org/apache/accumulo/accumulo/1.5. >>>>>>>>>>>> 1/accumulo-1.5.1-bin.tar.gz >>>>>>>>>>>> >>>>>>>>>>>> Changes since 1.5.1-RC2: ACCUMULO-2324, ACCUMULO-2361, >>>>>>>>>>>> >>>>>>>>>>>> ACCUMULO-2369, >>>>>>>>>>> >>>>>>>>>> >>>>>> ACCUMULO-2378, ACCUMULO-2379, ACCUMULO-2380, ACCUMULO-2385, >>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> ACCUMULO-2387, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> ACCUMULO-2390 >>>>>>>>>>>> >>>>>>>>>>>> Keys: http://www.apache.org/dist/accumulo/KEYS >>>>>>>>>>>> >>>>>>>>>>>> Final CHANGES: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a= >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> blob_plain;f=CHANGES;hb=3478f71ae888f8d73aaa93837319a6 >>>>>>>>>>>> dbb4ba0c8a >>>>>>>>>>>> >>>>>>>>>>>> Testing: Unit test and auto-tests passed successfully. Ran a >>>>>>>>>>>> >>>>>>>>>>> short >>> >>>> >>>>>>>>>>>> >>>>>>>>>>> (~2hrs) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> CI on 6 node installation. Ran a brief (~1hr) CI test on one >>>>>>>>>>>> >>>>>>>>>>>> machine >>>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>> with >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> the newly-released Hadoop-2.3.0. Built from src tarball, and >>>>>>>>>>>> >>>>>>>>>>>> verified >>>>>>>>>>> >>>>>>>>>> >>>>>> functionality with bin tarball. >>>>>>> >>>>>>>> >>>>>>>>>>>> Since there are very minor changes compared to 1.5.1-RC2, this >>>>>>>>>>>> >>>>>>>>>>> vote >>> >>>> >>>>>>>>>>>> >>>>>>>>>>> will >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> be open for the next 72 hours (2/28/2014 0100 UTC). >>>>>>>>>>>> >>>>>>>>>>>> Upon successful completion of this vote, a 1.5.1 gpg-signed Git >>>>>>>>>>>> >>>>>>>>>>> tag >>> >>>> >>>>>>>>>>>> >>>>>>>>>>> will >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> be created from 3478f71a and the above staging repository will >>>>>>>>>>>> be >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> promoted. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - Josh >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> -- >>> >>> Donald Miner >>> Chief Technology Officer >>> ClearEdge IT Solutions, LLC >>> Cell: 443 799 7807 >>> www.clearedgeit.com >>> >>> >>
