You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Keith Turner <ke...@deenlo.com> on 2013/11/14 21:41:52 UTC
[VOTE] Deprecate mock in 1.6.0
Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
1.5.0. I started thinking about this because I never added conditional
writer to mock.
[1] : https://issues.apache.org/jira/browse/ACCUMULO-878
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Nov 18, 2013 at 3:08 PM, Joey Echeverria
<jo...@clouderagovt.com>wrote:
> One word of warning. Hadoop deprecated the original MR API before the
> new API had feature parity and we're not stuck with both
> implementations, probably for the lifetime of Hadoop's MR bindings.
> I'm not in favor of deprecating something that people still have to
> use. You should deprecate when you have something for people to
> migrate to. I think MAC will fit some of the use cases, but it
>
For the use case of testing iterators quickly we have an alternative,
SortedMapIterator. For integration testing we have mini.
> certainly isn't a great fit for unit tests that can and should execute
> quickly.
>
Can you give some examples?
>
> -Joey
>
> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com> wrote:
> > I'll put the question out there:
> >
> > Is it an immediate non-starter to deprecate something that doesn't have
> an
> > immediate replacement?
> >
> > 1. You can still use it even if it's deprecated (and our usage of
> deprecated
> > typically falls under "we won't remove it before version X if not later")
> > 2. We know there are problems with it.
> > 3. We know we should be making other tools that better replace it (MAC)
> or
> > just give you a specific piece of functionality (iterator smoke-test
> > framework).
> >
> > Is this just my interpretation of how to interpret @Deprecated? It seems
> > completely logical to deprecate something we know isn't where we want to
> go
> > even if we aren't to where we want to go. Then, we start focusing on
> > making/improving the tools we want. This advertises to users that maybe
> they
> > might not want to rely on MockAccumulo.
> >
> >
> > On 11/18/13, 2:51 PM, Eric Newton wrote:
> >>
> >> I had this basic interaction with a user today:
> >>
> >> "I upgraded my old-style Filter to the Filter-as-iterator-Filter, how
> do I
> >> test it?"
> >>
> >> And the easiest thing to tell them was "use MockAccumulo". Without a
> >> better answer, I'm not for deprecating Mock.
> >>
> >> I agree that there is considerable effort in trying to keep Mock
> >> up-to-date, to the extent that I've not bothered to fix many of the
> >> failings of Mock.
> >>
> >>
> >>
> >> On Mon, Nov 18, 2013 at 2:09 PM, Christopher <ct...@apache.org>
> wrote:
> >>
> >>> Eric,
> >>>
> >>> Is there a reason these cannot be done in Mockito or EasyMock?
> >>>
> >>> --
> >>> Christopher L Tubbs II
> >>> http://gravatar.com/ctubbsii
> >>>
> >>>
> >>> On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com>
> >>> wrote:
> >>>>
> >>>> -1
> >>>>
> >>>> I'm a little more invested in Mock since I wrote the first instance of
> >>>
> >>> it.
> >>>>
> >>>> I know it does not simulate the accumulo API perfectly. And I know
> it
> >>>> adds some maintenance overhead for anyone adding new features to the
> >>>> API.
> >>>>
> >>>> However, adding additional testing requirements for a new API is
> >>>
> >>> something
> >>>>
> >>>> I like.
> >>>>
> >>>> Take a counter example: the "file://" hdfs implementation. It allows
> >>>> you
> >>>> to use the local file system through the same API you would use for
> the
> >>>> distributed file system.
> >>>>
> >>>> Except, it doesn't. It does not behave the same as hdfs. None of our
> >>>> recovery tests can use the local fs implementation because it just
> >>>
> >>> doesn't
> >>>>
> >>>> implement the proper flush semantics.
> >>>>
> >>>> Yet dozens of our own tests rely on the speedy availability of the
> local
> >>>
> >>> fs
> >>>>
> >>>> implementation.
> >>>>
> >>>> Having a fast way to test iterators that uses a test harness is not
> the
> >>>> same thing as testing the iterators using the same API they would use
> >>>> without Mock. I have long called for an iterator test harness to
> stress
> >>>> the issues of iterator lifetimes.
> >>>>
> >>>> Finally, I would humbly suggest that our software has stabilized to
> the
> >>>> point where we tests at all levels:
> >>>>
> >>>> * iterator stress tester
> >>>> * Mock API
> >>>> * Integration test using MAC
> >>>> * System tests that can be run at full scale
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com>
> wrote:
> >>>>
> >>>>> +1 for keeping a fast and easy (and well documented) mechanism for
> >>>>> debugging iterators. Perhaps the SortedMapiterator is the
> solution..but
> >>>
> >>> the
> >>>>>
> >>>>> key words here are 'well documented'
> >>>>>
> >>>>> -1 for continuing support a half implemented mock framework that we
> >>>
> >>> have to
> >>>>>
> >>>>> maintain. It makes code maintenance very hard when you couldnt, for
> >>>>> instance in the 1.3 series, even create a MockBatchDeleter. As Chris
> >>>>> stated, I agree that using the mock in the past had users walking the
> >>>
> >>> line
> >>>>>
> >>>>> too closely between unit and integration tests. With the mock, I
> could
> >>>>> write a bunch of fully valid tests against an iterator without the
> >>>
> >>> ability
> >>>>>
> >>>>> to verify that compactions didn't negatively affect my results.
> Except
> >>>
> >>> for
> >>>>>
> >>>>> being fast, the MAC mostly eliminates the need to use the mock for
> that
> >>>>> kind of test at all while it makes the tests more valid to an actual
> >>>>> runtime environment.
> >>>>>
> >>>>> +1 for mocking framework to be used in relevant unit tests. There are
> >>>
> >>> times
> >>>>>
> >>>>> when a quick and dirty mock is immensely useful and MAC is slow and
> way
> >>>>> overkill for those tasks. Perhaps it would be worth a ticket to
> >>>
> >>> investigate
> >>>>>
> >>>>> replacing the current usages of mockAccumulo (I haven't looked in
> >>>
> >>> awhile)
> >>>>>
> >>>>> with said mocking framework.
> >>>>>
> >>>>> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>> +1 (not really a voter)
> >>>>>>
> >>>>>> I think iterator unit tests should use SortedMapIterator, not
> anything
> >>>>>
> >>>>> like
> >>>>>>
> >>>>>> a full accumulo stack, and I think MAC is far more suitable for
> >>>>>
> >>>>> integration
> >>>>>>
> >>>>>> tests because it actually runs the same code...it's impossible for
> an
> >>>>>> outsider to tell in which behaviors mock reflects actual accumulo
> and
> >>>
> >>> in
> >>>>>>
> >>>>>> which it does something totally different.
> >>>>>>
> >>>>>> I do think MAC needs some help, but I think the process of excising
> >>>
> >>> mock
> >>>>>>
> >>>>>> from our own tests will flesh out what we need there better than
> >>>
> >>> anything
> >>>>>>
> >>>>>> else we could do.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
> >>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> *From:* Keith Turner [mailto:keith@deenlo.com]
> >>>>>>> *Sent:* Thursday, November 14, 2013 3:42 PM
> >>>>>>> *To:* dev@accumulo.apache.org; user@accumulo.apache.org
> >>>>>>> *Subject:* [VOTE] Deprecate mock in 1.6.0
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Should we deprecate mock accumulo for 1.6.0? This was considered
> >>>
> >>> [1]
> >>>>>
> >>>>> for
> >>>>>>>
> >>>>>>> 1.5.0. I started thinking about this because I never added
> >>>
> >>> conditional
> >>>>>>>
> >>>>>>> writer to mock.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> >>>>>>>
> >>>>>
> >>>
> >>
> >
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Joey Echeverria <jo...@clouderagovt.com>.
One word of warning. Hadoop deprecated the original MR API before the
new API had feature parity and we're not stuck with both
implementations, probably for the lifetime of Hadoop's MR bindings.
I'm not in favor of deprecating something that people still have to
use. You should deprecate when you have something for people to
migrate to. I think MAC will fit some of the use cases, but it
certainly isn't a great fit for unit tests that can and should execute
quickly.
-Joey
On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com> wrote:
> I'll put the question out there:
>
> Is it an immediate non-starter to deprecate something that doesn't have an
> immediate replacement?
>
> 1. You can still use it even if it's deprecated (and our usage of deprecated
> typically falls under "we won't remove it before version X if not later")
> 2. We know there are problems with it.
> 3. We know we should be making other tools that better replace it (MAC) or
> just give you a specific piece of functionality (iterator smoke-test
> framework).
>
> Is this just my interpretation of how to interpret @Deprecated? It seems
> completely logical to deprecate something we know isn't where we want to go
> even if we aren't to where we want to go. Then, we start focusing on
> making/improving the tools we want. This advertises to users that maybe they
> might not want to rely on MockAccumulo.
>
>
> On 11/18/13, 2:51 PM, Eric Newton wrote:
>>
>> I had this basic interaction with a user today:
>>
>> "I upgraded my old-style Filter to the Filter-as-iterator-Filter, how do I
>> test it?"
>>
>> And the easiest thing to tell them was "use MockAccumulo". Without a
>> better answer, I'm not for deprecating Mock.
>>
>> I agree that there is considerable effort in trying to keep Mock
>> up-to-date, to the extent that I've not bothered to fix many of the
>> failings of Mock.
>>
>>
>>
>> On Mon, Nov 18, 2013 at 2:09 PM, Christopher <ct...@apache.org> wrote:
>>
>>> Eric,
>>>
>>> Is there a reason these cannot be done in Mockito or EasyMock?
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com>
>>> wrote:
>>>>
>>>> -1
>>>>
>>>> I'm a little more invested in Mock since I wrote the first instance of
>>>
>>> it.
>>>>
>>>> I know it does not simulate the accumulo API perfectly. And I know it
>>>> adds some maintenance overhead for anyone adding new features to the
>>>> API.
>>>>
>>>> However, adding additional testing requirements for a new API is
>>>
>>> something
>>>>
>>>> I like.
>>>>
>>>> Take a counter example: the "file://" hdfs implementation. It allows
>>>> you
>>>> to use the local file system through the same API you would use for the
>>>> distributed file system.
>>>>
>>>> Except, it doesn't. It does not behave the same as hdfs. None of our
>>>> recovery tests can use the local fs implementation because it just
>>>
>>> doesn't
>>>>
>>>> implement the proper flush semantics.
>>>>
>>>> Yet dozens of our own tests rely on the speedy availability of the local
>>>
>>> fs
>>>>
>>>> implementation.
>>>>
>>>> Having a fast way to test iterators that uses a test harness is not the
>>>> same thing as testing the iterators using the same API they would use
>>>> without Mock. I have long called for an iterator test harness to stress
>>>> the issues of iterator lifetimes.
>>>>
>>>> Finally, I would humbly suggest that our software has stabilized to the
>>>> point where we tests at all levels:
>>>>
>>>> * iterator stress tester
>>>> * Mock API
>>>> * Integration test using MAC
>>>> * System tests that can be run at full scale
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com> wrote:
>>>>
>>>>> +1 for keeping a fast and easy (and well documented) mechanism for
>>>>> debugging iterators. Perhaps the SortedMapiterator is the solution..but
>>>
>>> the
>>>>>
>>>>> key words here are 'well documented'
>>>>>
>>>>> -1 for continuing support a half implemented mock framework that we
>>>
>>> have to
>>>>>
>>>>> maintain. It makes code maintenance very hard when you couldnt, for
>>>>> instance in the 1.3 series, even create a MockBatchDeleter. As Chris
>>>>> stated, I agree that using the mock in the past had users walking the
>>>
>>> line
>>>>>
>>>>> too closely between unit and integration tests. With the mock, I could
>>>>> write a bunch of fully valid tests against an iterator without the
>>>
>>> ability
>>>>>
>>>>> to verify that compactions didn't negatively affect my results. Except
>>>
>>> for
>>>>>
>>>>> being fast, the MAC mostly eliminates the need to use the mock for that
>>>>> kind of test at all while it makes the tests more valid to an actual
>>>>> runtime environment.
>>>>>
>>>>> +1 for mocking framework to be used in relevant unit tests. There are
>>>
>>> times
>>>>>
>>>>> when a quick and dirty mock is immensely useful and MAC is slow and way
>>>>> overkill for those tasks. Perhaps it would be worth a ticket to
>>>
>>> investigate
>>>>>
>>>>> replacing the current usages of mockAccumulo (I haven't looked in
>>>
>>> awhile)
>>>>>
>>>>> with said mocking framework.
>>>>>
>>>>> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
>>>>>>
>>>>>>
>>>>>> +1 (not really a voter)
>>>>>>
>>>>>> I think iterator unit tests should use SortedMapIterator, not anything
>>>>>
>>>>> like
>>>>>>
>>>>>> a full accumulo stack, and I think MAC is far more suitable for
>>>>>
>>>>> integration
>>>>>>
>>>>>> tests because it actually runs the same code...it's impossible for an
>>>>>> outsider to tell in which behaviors mock reflects actual accumulo and
>>>
>>> in
>>>>>>
>>>>>> which it does something totally different.
>>>>>>
>>>>>> I do think MAC needs some help, but I think the process of excising
>>>
>>> mock
>>>>>>
>>>>>> from our own tests will flesh out what we need there better than
>>>
>>> anything
>>>>>>
>>>>>> else we could do.
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* Keith Turner [mailto:keith@deenlo.com]
>>>>>>> *Sent:* Thursday, November 14, 2013 3:42 PM
>>>>>>> *To:* dev@accumulo.apache.org; user@accumulo.apache.org
>>>>>>> *Subject:* [VOTE] Deprecate mock in 1.6.0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Should we deprecate mock accumulo for 1.6.0? This was considered
>>>
>>> [1]
>>>>>
>>>>> for
>>>>>>>
>>>>>>> 1.5.0. I started thinking about this because I never added
>>>
>>> conditional
>>>>>>>
>>>>>>> writer to mock.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>>>>>>
>>>>>
>>>
>>
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Christopher <ct...@apache.org>.
I like this idea.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Nov 19, 2013 at 1:22 PM, Bill Havanki <bh...@clouderagovt.com> wrote:
> A compromise would be to move MockAccumulo to its own subproject, and
> deprecate the copy resident in the public API. Then, it can start to drift
> toward a side project that those interested in maintaining can work with,
> but that does not need to be kept in lockstep with the arrival of new
> features.
>
> The side project never needs to be deprecated, but the core project has the
> option to migrate away from it over time. Users can switch over to it if
> they want to continue using it.
>
> Bill
>
>
> On Mon, Nov 18, 2013 at 5:45 PM, Christopher <ct...@apache.org> wrote:
>
>> Ugh. Okay. I hadn't realized this.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey <bu...@clouderagovt.com>
>> wrote:
>> > On Mon, Nov 18, 2013 at 4:26 PM, Christopher <ct...@apache.org>
>> wrote:
>> >
>> >> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com>
>> wrote:
>> >>
>> >> > Is this just my interpretation of how to interpret @Deprecated? It
>> seems
>> >> > completely logical to deprecate something we know isn't where we want
>> to
>> >> go
>> >> > even if we aren't to where we want to go. Then, we start focusing on
>> >> > making/improving the tools we want. This advertises to users that
>> maybe
>> >> they
>> >> > might not want to rely on MockAccumulo.
>> >>
>> >> I agree.
>> >>
>> >> And, I don't think Joey's point about the M/R API in Hadoop applies
>> >> here. MockAccumulo was never part of our "public API". It's
>> >> developer-facing and intended for testing... not core to working with
>> >> Accumulo.
>> >>
>> >>
>> > Mock most definitely is a part of our public api for 1.4.x and 1.5.x.
>> Both
>> > READMEs basically say the same:
>> >
>> >
>> > 9. API
>> >
>> > The public accumulo API is composed of :
>> >
>> > * everything under org.apache.accumulo.core.client, excluding impl
>> packages
>> > * Key, Mutation, Value, and Range in org.apache.accumulo.core.data.
>> > * org.apache.accumulo.server.mini
>> >
>> > To get started using accumulo review the example and the javadoc for the
>> > packages and classes mentioned above.
>> >
>> >
>> > Mock is in org.apache.accumulo.core.client.mock which means it's a part
>> of
>> > the public API.
>> >
>> >
>> > --
>> > Sean
>>
>
>
>
> --
> | - - -
> | Bill Havanki
> | Solutions Architect, Cloudera Government Solutions
> | - - -
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Keith Turner <ke...@deenlo.com>.
On Wed, Nov 20, 2013 at 12:13 AM, Josh Elser <jo...@gmail.com> wrote:
> I think I may have convinced myself otherwise talking to Billie today.
>
> MockAccumulo has been the way it is for some time now (two, going on
> three, major releases). We know it's not ideal and has internal
> limitations. It doesn't make sense to me to devote more time into it
> knowing that. For the same
Its good to understand the history. It was introduced in 1.3, major
improvements in behavior were made in 1.4, mini was introduced in 1.5, in
1.6 I feel like mock is adrift.
> reasons, it doesn't make sense for us to spend time moving it for the sake
> of moving it, because at the end of the day, it's still the same code it
> was before.
>
> 0 to deprecate under the notion that we have other stuff that we can work
> on that's likely more pressing. I'd say -1, but if someone feels that it is
> worth the effort, I'm not one to tell them not to do it.
>
I think clearly communicating things we developers know to users should be
a pressing matter. I suppose we can choose to let users find out the true
state of things on their own.
I do agree that this discussion has been a time sink. At this point I am
just going to give up on this issue. I will not take any action to
deprecate mock and I also will not add conditional writer support to it.
So the matter is settled for me.
For future discussion, if you vote -1 and someone ask you a direct question
please answer. Your votes are what prevent someone from moving forward, so
you need to defend them.
>
> Fix MockAccumulo to "throw new NotImplementedExceptions()" where necessary
> for API additions (if it doesn't already).
>
> Strong +1 to seriously look into trying to speeding up MAC, creating an
> iterator test-harness and other testing tools in the 1.7.0 time frame.
>
>
> On 11/19/13, 1:22 PM, Bill Havanki wrote:
>
>> A compromise would be to move MockAccumulo to its own subproject, and
>> deprecate the copy resident in the public API. Then, it can start to drift
>> toward a side project that those interested in maintaining can work with,
>> but that does not need to be kept in lockstep with the arrival of new
>> features.
>>
>> The side project never needs to be deprecated, but the core project has
>> the
>> option to migrate away from it over time. Users can switch over to it if
>> they want to continue using it.
>>
>> Bill
>>
>>
>> On Mon, Nov 18, 2013 at 5:45 PM, Christopher <ct...@apache.org> wrote:
>>
>> Ugh. Okay. I hadn't realized this.
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey <busbey+ml@clouderagovt.com
>>> >
>>> wrote:
>>>
>>>> On Mon, Nov 18, 2013 at 4:26 PM, Christopher <ct...@apache.org>
>>>>
>>> wrote:
>>>
>>>>
>>>> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com>
>>>>>
>>>> wrote:
>>>
>>>>
>>>>> Is this just my interpretation of how to interpret @Deprecated? It
>>>>>>
>>>>> seems
>>>
>>>> completely logical to deprecate something we know isn't where we want
>>>>>>
>>>>> to
>>>
>>>> go
>>>>>
>>>>>> even if we aren't to where we want to go. Then, we start focusing on
>>>>>> making/improving the tools we want. This advertises to users that
>>>>>>
>>>>> maybe
>>>
>>>> they
>>>>>
>>>>>> might not want to rely on MockAccumulo.
>>>>>>
>>>>>
>>>>> I agree.
>>>>>
>>>>> And, I don't think Joey's point about the M/R API in Hadoop applies
>>>>> here. MockAccumulo was never part of our "public API". It's
>>>>> developer-facing and intended for testing... not core to working with
>>>>> Accumulo.
>>>>>
>>>>>
>>>>> Mock most definitely is a part of our public api for 1.4.x and 1.5.x.
>>>>
>>> Both
>>>
>>>> READMEs basically say the same:
>>>>
>>>>
>>>> 9. API
>>>>
>>>> The public accumulo API is composed of :
>>>>
>>>> * everything under org.apache.accumulo.core.client, excluding impl
>>>>
>>> packages
>>>
>>>> * Key, Mutation, Value, and Range in org.apache.accumulo.core.data.
>>>> * org.apache.accumulo.server.mini
>>>>
>>>> To get started using accumulo review the example and the javadoc for the
>>>> packages and classes mentioned above.
>>>>
>>>>
>>>> Mock is in org.apache.accumulo.core.client.mock which means it's a part
>>>>
>>> of
>>>
>>>> the public API.
>>>>
>>>>
>>>> --
>>>> Sean
>>>>
>>>
>>>
>>
>>
>>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Josh Elser <jo...@gmail.com>.
I think I may have convinced myself otherwise talking to Billie today.
MockAccumulo has been the way it is for some time now (two, going on
three, major releases). We know it's not ideal and has internal
limitations. It doesn't make sense to me to devote more time into it
knowing that. For the same reasons, it doesn't make sense for us to
spend time moving it for the sake of moving it, because at the end of
the day, it's still the same code it was before.
0 to deprecate under the notion that we have other stuff that we can
work on that's likely more pressing. I'd say -1, but if someone feels
that it is worth the effort, I'm not one to tell them not to do it.
Fix MockAccumulo to "throw new NotImplementedExceptions()" where
necessary for API additions (if it doesn't already).
Strong +1 to seriously look into trying to speeding up MAC, creating an
iterator test-harness and other testing tools in the 1.7.0 time frame.
On 11/19/13, 1:22 PM, Bill Havanki wrote:
> A compromise would be to move MockAccumulo to its own subproject, and
> deprecate the copy resident in the public API. Then, it can start to drift
> toward a side project that those interested in maintaining can work with,
> but that does not need to be kept in lockstep with the arrival of new
> features.
>
> The side project never needs to be deprecated, but the core project has the
> option to migrate away from it over time. Users can switch over to it if
> they want to continue using it.
>
> Bill
>
>
> On Mon, Nov 18, 2013 at 5:45 PM, Christopher <ct...@apache.org> wrote:
>
>> Ugh. Okay. I hadn't realized this.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey <bu...@clouderagovt.com>
>> wrote:
>>> On Mon, Nov 18, 2013 at 4:26 PM, Christopher <ct...@apache.org>
>> wrote:
>>>
>>>> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com>
>> wrote:
>>>>
>>>>> Is this just my interpretation of how to interpret @Deprecated? It
>> seems
>>>>> completely logical to deprecate something we know isn't where we want
>> to
>>>> go
>>>>> even if we aren't to where we want to go. Then, we start focusing on
>>>>> making/improving the tools we want. This advertises to users that
>> maybe
>>>> they
>>>>> might not want to rely on MockAccumulo.
>>>>
>>>> I agree.
>>>>
>>>> And, I don't think Joey's point about the M/R API in Hadoop applies
>>>> here. MockAccumulo was never part of our "public API". It's
>>>> developer-facing and intended for testing... not core to working with
>>>> Accumulo.
>>>>
>>>>
>>> Mock most definitely is a part of our public api for 1.4.x and 1.5.x.
>> Both
>>> READMEs basically say the same:
>>>
>>>
>>> 9. API
>>>
>>> The public accumulo API is composed of :
>>>
>>> * everything under org.apache.accumulo.core.client, excluding impl
>> packages
>>> * Key, Mutation, Value, and Range in org.apache.accumulo.core.data.
>>> * org.apache.accumulo.server.mini
>>>
>>> To get started using accumulo review the example and the javadoc for the
>>> packages and classes mentioned above.
>>>
>>>
>>> Mock is in org.apache.accumulo.core.client.mock which means it's a part
>> of
>>> the public API.
>>>
>>>
>>> --
>>> Sean
>>
>
>
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Bill Havanki <bh...@clouderagovt.com>.
A compromise would be to move MockAccumulo to its own subproject, and
deprecate the copy resident in the public API. Then, it can start to drift
toward a side project that those interested in maintaining can work with,
but that does not need to be kept in lockstep with the arrival of new
features.
The side project never needs to be deprecated, but the core project has the
option to migrate away from it over time. Users can switch over to it if
they want to continue using it.
Bill
On Mon, Nov 18, 2013 at 5:45 PM, Christopher <ct...@apache.org> wrote:
> Ugh. Okay. I hadn't realized this.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey <bu...@clouderagovt.com>
> wrote:
> > On Mon, Nov 18, 2013 at 4:26 PM, Christopher <ct...@apache.org>
> wrote:
> >
> >> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com>
> wrote:
> >>
> >> > Is this just my interpretation of how to interpret @Deprecated? It
> seems
> >> > completely logical to deprecate something we know isn't where we want
> to
> >> go
> >> > even if we aren't to where we want to go. Then, we start focusing on
> >> > making/improving the tools we want. This advertises to users that
> maybe
> >> they
> >> > might not want to rely on MockAccumulo.
> >>
> >> I agree.
> >>
> >> And, I don't think Joey's point about the M/R API in Hadoop applies
> >> here. MockAccumulo was never part of our "public API". It's
> >> developer-facing and intended for testing... not core to working with
> >> Accumulo.
> >>
> >>
> > Mock most definitely is a part of our public api for 1.4.x and 1.5.x.
> Both
> > READMEs basically say the same:
> >
> >
> > 9. API
> >
> > The public accumulo API is composed of :
> >
> > * everything under org.apache.accumulo.core.client, excluding impl
> packages
> > * Key, Mutation, Value, and Range in org.apache.accumulo.core.data.
> > * org.apache.accumulo.server.mini
> >
> > To get started using accumulo review the example and the javadoc for the
> > packages and classes mentioned above.
> >
> >
> > Mock is in org.apache.accumulo.core.client.mock which means it's a part
> of
> > the public API.
> >
> >
> > --
> > Sean
>
--
| - - -
| Bill Havanki
| Solutions Architect, Cloudera Government Solutions
| - - -
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Christopher <ct...@apache.org>.
Ugh. Okay. I hadn't realized this.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Nov 18, 2013 at 5:33 PM, Sean Busbey <bu...@clouderagovt.com> wrote:
> On Mon, Nov 18, 2013 at 4:26 PM, Christopher <ct...@apache.org> wrote:
>
>> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com> wrote:
>>
>> > Is this just my interpretation of how to interpret @Deprecated? It seems
>> > completely logical to deprecate something we know isn't where we want to
>> go
>> > even if we aren't to where we want to go. Then, we start focusing on
>> > making/improving the tools we want. This advertises to users that maybe
>> they
>> > might not want to rely on MockAccumulo.
>>
>> I agree.
>>
>> And, I don't think Joey's point about the M/R API in Hadoop applies
>> here. MockAccumulo was never part of our "public API". It's
>> developer-facing and intended for testing... not core to working with
>> Accumulo.
>>
>>
> Mock most definitely is a part of our public api for 1.4.x and 1.5.x. Both
> READMEs basically say the same:
>
>
> 9. API
>
> The public accumulo API is composed of :
>
> * everything under org.apache.accumulo.core.client, excluding impl packages
> * Key, Mutation, Value, and Range in org.apache.accumulo.core.data.
> * org.apache.accumulo.server.mini
>
> To get started using accumulo review the example and the javadoc for the
> packages and classes mentioned above.
>
>
> Mock is in org.apache.accumulo.core.client.mock which means it's a part of
> the public API.
>
>
> --
> Sean
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Sean Busbey <bu...@clouderagovt.com>.
On Mon, Nov 18, 2013 at 4:26 PM, Christopher <ct...@apache.org> wrote:
> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Is this just my interpretation of how to interpret @Deprecated? It seems
> > completely logical to deprecate something we know isn't where we want to
> go
> > even if we aren't to where we want to go. Then, we start focusing on
> > making/improving the tools we want. This advertises to users that maybe
> they
> > might not want to rely on MockAccumulo.
>
> I agree.
>
> And, I don't think Joey's point about the M/R API in Hadoop applies
> here. MockAccumulo was never part of our "public API". It's
> developer-facing and intended for testing... not core to working with
> Accumulo.
>
>
Mock most definitely is a part of our public api for 1.4.x and 1.5.x. Both
READMEs basically say the same:
9. API
The public accumulo API is composed of :
* everything under org.apache.accumulo.core.client, excluding impl packages
* Key, Mutation, Value, and Range in org.apache.accumulo.core.data.
* org.apache.accumulo.server.mini
To get started using accumulo review the example and the javadoc for the
packages and classes mentioned above.
Mock is in org.apache.accumulo.core.client.mock which means it's a part of
the public API.
--
Sean
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Christopher <ct...@apache.org>.
On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com> wrote:
> I'll put the question out there:
>
> Is it an immediate non-starter to deprecate something that doesn't have an
> immediate replacement?
I don't think so. For instance, we may not need the feature, or it may
have been poorly designed and unnecessary. In any case, we do have
immediate replacements for MockAccumulo. Perhaps they aren't as ideal,
but they have the value of being more reliable.
> 1. You can still use it even if it's deprecated (and our usage of deprecated
> typically falls under "we won't remove it before version X if not later")
> 2. We know there are problems with it.
> 3. We know we should be making other tools that better replace it (MAC) or
> just give you a specific piece of functionality (iterator smoke-test
> framework).
>
> Is this just my interpretation of how to interpret @Deprecated? It seems
> completely logical to deprecate something we know isn't where we want to go
> even if we aren't to where we want to go. Then, we start focusing on
> making/improving the tools we want. This advertises to users that maybe they
> might not want to rely on MockAccumulo.
I agree.
And, I don't think Joey's point about the M/R API in Hadoop applies
here. MockAccumulo was never part of our "public API". It's
developer-facing and intended for testing... not core to working with
Accumulo.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
> On 11/18/13, 2:51 PM, Eric Newton wrote:
>>
>> I had this basic interaction with a user today:
>>
>> "I upgraded my old-style Filter to the Filter-as-iterator-Filter, how do I
>> test it?"
>>
>> And the easiest thing to tell them was "use MockAccumulo". Without a
>> better answer, I'm not for deprecating Mock.
>>
>> I agree that there is considerable effort in trying to keep Mock
>> up-to-date, to the extent that I've not bothered to fix many of the
>> failings of Mock.
>>
>>
>>
>> On Mon, Nov 18, 2013 at 2:09 PM, Christopher <ct...@apache.org> wrote:
>>
>>> Eric,
>>>
>>> Is there a reason these cannot be done in Mockito or EasyMock?
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com>
>>> wrote:
>>>>
>>>> -1
>>>>
>>>> I'm a little more invested in Mock since I wrote the first instance of
>>>
>>> it.
>>>>
>>>> I know it does not simulate the accumulo API perfectly. And I know it
>>>> adds some maintenance overhead for anyone adding new features to the
>>>> API.
>>>>
>>>> However, adding additional testing requirements for a new API is
>>>
>>> something
>>>>
>>>> I like.
>>>>
>>>> Take a counter example: the "file://" hdfs implementation. It allows
>>>> you
>>>> to use the local file system through the same API you would use for the
>>>> distributed file system.
>>>>
>>>> Except, it doesn't. It does not behave the same as hdfs. None of our
>>>> recovery tests can use the local fs implementation because it just
>>>
>>> doesn't
>>>>
>>>> implement the proper flush semantics.
>>>>
>>>> Yet dozens of our own tests rely on the speedy availability of the local
>>>
>>> fs
>>>>
>>>> implementation.
>>>>
>>>> Having a fast way to test iterators that uses a test harness is not the
>>>> same thing as testing the iterators using the same API they would use
>>>> without Mock. I have long called for an iterator test harness to stress
>>>> the issues of iterator lifetimes.
>>>>
>>>> Finally, I would humbly suggest that our software has stabilized to the
>>>> point where we tests at all levels:
>>>>
>>>> * iterator stress tester
>>>> * Mock API
>>>> * Integration test using MAC
>>>> * System tests that can be run at full scale
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com> wrote:
>>>>
>>>>> +1 for keeping a fast and easy (and well documented) mechanism for
>>>>> debugging iterators. Perhaps the SortedMapiterator is the solution..but
>>>
>>> the
>>>>>
>>>>> key words here are 'well documented'
>>>>>
>>>>> -1 for continuing support a half implemented mock framework that we
>>>
>>> have to
>>>>>
>>>>> maintain. It makes code maintenance very hard when you couldnt, for
>>>>> instance in the 1.3 series, even create a MockBatchDeleter. As Chris
>>>>> stated, I agree that using the mock in the past had users walking the
>>>
>>> line
>>>>>
>>>>> too closely between unit and integration tests. With the mock, I could
>>>>> write a bunch of fully valid tests against an iterator without the
>>>
>>> ability
>>>>>
>>>>> to verify that compactions didn't negatively affect my results. Except
>>>
>>> for
>>>>>
>>>>> being fast, the MAC mostly eliminates the need to use the mock for that
>>>>> kind of test at all while it makes the tests more valid to an actual
>>>>> runtime environment.
>>>>>
>>>>> +1 for mocking framework to be used in relevant unit tests. There are
>>>
>>> times
>>>>>
>>>>> when a quick and dirty mock is immensely useful and MAC is slow and way
>>>>> overkill for those tasks. Perhaps it would be worth a ticket to
>>>
>>> investigate
>>>>>
>>>>> replacing the current usages of mockAccumulo (I haven't looked in
>>>
>>> awhile)
>>>>>
>>>>> with said mocking framework.
>>>>>
>>>>> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
>>>>>>
>>>>>>
>>>>>> +1 (not really a voter)
>>>>>>
>>>>>> I think iterator unit tests should use SortedMapIterator, not anything
>>>>>
>>>>> like
>>>>>>
>>>>>> a full accumulo stack, and I think MAC is far more suitable for
>>>>>
>>>>> integration
>>>>>>
>>>>>> tests because it actually runs the same code...it's impossible for an
>>>>>> outsider to tell in which behaviors mock reflects actual accumulo and
>>>
>>> in
>>>>>>
>>>>>> which it does something totally different.
>>>>>>
>>>>>> I do think MAC needs some help, but I think the process of excising
>>>
>>> mock
>>>>>>
>>>>>> from our own tests will flesh out what we need there better than
>>>
>>> anything
>>>>>>
>>>>>> else we could do.
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* Keith Turner [mailto:keith@deenlo.com]
>>>>>>> *Sent:* Thursday, November 14, 2013 3:42 PM
>>>>>>> *To:* dev@accumulo.apache.org; user@accumulo.apache.org
>>>>>>> *Subject:* [VOTE] Deprecate mock in 1.6.0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Should we deprecate mock accumulo for 1.6.0? This was considered
>>>
>>> [1]
>>>>>
>>>>> for
>>>>>>>
>>>>>>> 1.5.0. I started thinking about this because I never added
>>>
>>> conditional
>>>>>>>
>>>>>>> writer to mock.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>>>>>>
>>>>>
>>>
>>
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Nov 18, 2013 at 4:01 PM, John Vines <vi...@apache.org> wrote:
> And I'm a firm advocate of #2. Joey makes a good point about the foibles of
>
Do you think new features like namespaces and conditional writer should be
rejected unless they have support for mock?
> premature deprecation (albeit not as drastic as his case) and Eric made an
> extremely cromulent point about the benefits of mock that aren't available
> elsewhere currently.
>
>
> On Mon, Nov 18, 2013 at 3:54 PM, Keith Turner <ke...@deenlo.com> wrote:
>
> > On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com>
> wrote:
> >
> > > I'll put the question out there:
> > >
> > > Is it an immediate non-starter to deprecate something that doesn't have
> > an
> > > immediate replacement?
> > >
> > > 1. You can still use it even if it's deprecated (and our usage of
> > > deprecated typically falls under "we won't remove it before version X
> if
> > > not later")
> > > 2. We know there are problems with it.
> > > 3. We know we should be making other tools that better replace it (MAC)
> > or
> > > just give you a specific piece of functionality (iterator smoke-test
> > > framework).
> > >
> > > Is this just my interpretation of how to interpret @Deprecated? It
> seems
> > > completely logical to deprecate something we know isn't where we want
> to
> > go
> > > even if we aren't to where we want to go. Then, we start focusing on
> > > making/improving the tools we want. This advertises to users that maybe
> > > they might not want to rely on MockAccumulo.
> >
> >
> > I agree. I am thinking that if we do not maintain it, then its
> > deprecated whether we declare it or not. We at least 3 options :
> >
> > 1. Deprecate mock
> > 2. Maintain mock (add new Accumulo features and actively fix bugs)
> > 3. Leave it as is
> >
> > I think we should choose 1 or 2, but not choose 3.
> >
> >
> >
> > >
> > > On 11/18/13, 2:51 PM, Eric Newton wrote:
> > >
> > >> I had this basic interaction with a user today:
> > >>
> > >> "I upgraded my old-style Filter to the Filter-as-iterator-Filter, how
> > do I
> > >> test it?"
> > >>
> > >> And the easiest thing to tell them was "use MockAccumulo". Without a
> > >> better answer, I'm not for deprecating Mock.
> > >>
> > >> I agree that there is considerable effort in trying to keep Mock
> > >> up-to-date, to the extent that I've not bothered to fix many of the
> > >> failings of Mock.
> > >>
> > >>
> > >>
> > >> On Mon, Nov 18, 2013 at 2:09 PM, Christopher <ct...@apache.org>
> > wrote:
> > >>
> > >> Eric,
> > >>>
> > >>> Is there a reason these cannot be done in Mockito or EasyMock?
> > >>>
> > >>> --
> > >>> Christopher L Tubbs II
> > >>> http://gravatar.com/ctubbsii
> > >>>
> > >>>
> > >>> On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> -1
> > >>>>
> > >>>> I'm a little more invested in Mock since I wrote the first instance
> of
> > >>>>
> > >>> it.
> > >>>
> > >>>> I know it does not simulate the accumulo API perfectly. And I
> know
> > it
> > >>>> adds some maintenance overhead for anyone adding new features to the
> > >>>> API.
> > >>>>
> > >>>> However, adding additional testing requirements for a new API is
> > >>>>
> > >>> something
> > >>>
> > >>>> I like.
> > >>>>
> > >>>> Take a counter example: the "file://" hdfs implementation. It
> allows
> > >>>> you
> > >>>> to use the local file system through the same API you would use for
> > the
> > >>>> distributed file system.
> > >>>>
> > >>>> Except, it doesn't. It does not behave the same as hdfs. None of
> our
> > >>>> recovery tests can use the local fs implementation because it just
> > >>>>
> > >>> doesn't
> > >>>
> > >>>> implement the proper flush semantics.
> > >>>>
> > >>>> Yet dozens of our own tests rely on the speedy availability of the
> > local
> > >>>>
> > >>> fs
> > >>>
> > >>>> implementation.
> > >>>>
> > >>>> Having a fast way to test iterators that uses a test harness is not
> > the
> > >>>> same thing as testing the iterators using the same API they would
> use
> > >>>> without Mock. I have long called for an iterator test harness to
> > stress
> > >>>> the issues of iterator lifetimes.
> > >>>>
> > >>>> Finally, I would humbly suggest that our software has stabilized to
> > the
> > >>>> point where we tests at all levels:
> > >>>>
> > >>>> * iterator stress tester
> > >>>> * Mock API
> > >>>> * Integration test using MAC
> > >>>> * System tests that can be run at full scale
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com>
> > wrote:
> > >>>>
> > >>>> +1 for keeping a fast and easy (and well documented) mechanism for
> > >>>>> debugging iterators. Perhaps the SortedMapiterator is the
> > solution..but
> > >>>>>
> > >>>> the
> > >>>
> > >>>> key words here are 'well documented'
> > >>>>>
> > >>>>> -1 for continuing support a half implemented mock framework that we
> > >>>>>
> > >>>> have to
> > >>>
> > >>>> maintain. It makes code maintenance very hard when you couldnt, for
> > >>>>> instance in the 1.3 series, even create a MockBatchDeleter. As
> Chris
> > >>>>> stated, I agree that using the mock in the past had users walking
> the
> > >>>>>
> > >>>> line
> > >>>
> > >>>> too closely between unit and integration tests. With the mock, I
> could
> > >>>>> write a bunch of fully valid tests against an iterator without the
> > >>>>>
> > >>>> ability
> > >>>
> > >>>> to verify that compactions didn't negatively affect my results.
> Except
> > >>>>>
> > >>>> for
> > >>>
> > >>>> being fast, the MAC mostly eliminates the need to use the mock for
> > that
> > >>>>> kind of test at all while it makes the tests more valid to an
> actual
> > >>>>> runtime environment.
> > >>>>>
> > >>>>> +1 for mocking framework to be used in relevant unit tests. There
> are
> > >>>>>
> > >>>> times
> > >>>
> > >>>> when a quick and dirty mock is immensely useful and MAC is slow and
> > way
> > >>>>> overkill for those tasks. Perhaps it would be worth a ticket to
> > >>>>>
> > >>>> investigate
> > >>>
> > >>>> replacing the current usages of mockAccumulo (I haven't looked in
> > >>>>>
> > >>>> awhile)
> > >>>
> > >>>> with said mocking framework.
> > >>>>>
> > >>>>> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com>
> wrote:
> > >>>>>
> > >>>>>>
> > >>>>>> +1 (not really a voter)
> > >>>>>>
> > >>>>>> I think iterator unit tests should use SortedMapIterator, not
> > anything
> > >>>>>>
> > >>>>> like
> > >>>>>
> > >>>>>> a full accumulo stack, and I think MAC is far more suitable for
> > >>>>>>
> > >>>>> integration
> > >>>>>
> > >>>>>> tests because it actually runs the same code...it's impossible for
> > an
> > >>>>>> outsider to tell in which behaviors mock reflects actual accumulo
> > and
> > >>>>>>
> > >>>>> in
> > >>>
> > >>>> which it does something totally different.
> > >>>>>>
> > >>>>>> I do think MAC needs some help, but I think the process of
> excising
> > >>>>>>
> > >>>>> mock
> > >>>
> > >>>> from our own tests will flesh out what we need there better than
> > >>>>>>
> > >>>>> anything
> > >>>
> > >>>> else we could do.
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
> > >>>>>>
> > >>>>>> +1
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> *From:* Keith Turner [mailto:keith@deenlo.com]
> > >>>>>>> *Sent:* Thursday, November 14, 2013 3:42 PM
> > >>>>>>> *To:* dev@accumulo.apache.org; user@accumulo.apache.org
> > >>>>>>> *Subject:* [VOTE] Deprecate mock in 1.6.0
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Should we deprecate mock accumulo for 1.6.0? This was considered
> > >>>>>>>
> > >>>>>> [1]
> > >>>
> > >>>> for
> > >>>>>
> > >>>>>> 1.5.0. I started thinking about this because I never added
> > >>>>>>>
> > >>>>>> conditional
> > >>>
> > >>>> writer to mock.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by John Vines <vi...@apache.org>.
And I'm a firm advocate of #2. Joey makes a good point about the foibles of
premature deprecation (albeit not as drastic as his case) and Eric made an
extremely cromulent point about the benefits of mock that aren't available
elsewhere currently.
On Mon, Nov 18, 2013 at 3:54 PM, Keith Turner <ke...@deenlo.com> wrote:
> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > I'll put the question out there:
> >
> > Is it an immediate non-starter to deprecate something that doesn't have
> an
> > immediate replacement?
> >
> > 1. You can still use it even if it's deprecated (and our usage of
> > deprecated typically falls under "we won't remove it before version X if
> > not later")
> > 2. We know there are problems with it.
> > 3. We know we should be making other tools that better replace it (MAC)
> or
> > just give you a specific piece of functionality (iterator smoke-test
> > framework).
> >
> > Is this just my interpretation of how to interpret @Deprecated? It seems
> > completely logical to deprecate something we know isn't where we want to
> go
> > even if we aren't to where we want to go. Then, we start focusing on
> > making/improving the tools we want. This advertises to users that maybe
> > they might not want to rely on MockAccumulo.
>
>
> I agree. I am thinking that if we do not maintain it, then its
> deprecated whether we declare it or not. We at least 3 options :
>
> 1. Deprecate mock
> 2. Maintain mock (add new Accumulo features and actively fix bugs)
> 3. Leave it as is
>
> I think we should choose 1 or 2, but not choose 3.
>
>
>
> >
> > On 11/18/13, 2:51 PM, Eric Newton wrote:
> >
> >> I had this basic interaction with a user today:
> >>
> >> "I upgraded my old-style Filter to the Filter-as-iterator-Filter, how
> do I
> >> test it?"
> >>
> >> And the easiest thing to tell them was "use MockAccumulo". Without a
> >> better answer, I'm not for deprecating Mock.
> >>
> >> I agree that there is considerable effort in trying to keep Mock
> >> up-to-date, to the extent that I've not bothered to fix many of the
> >> failings of Mock.
> >>
> >>
> >>
> >> On Mon, Nov 18, 2013 at 2:09 PM, Christopher <ct...@apache.org>
> wrote:
> >>
> >> Eric,
> >>>
> >>> Is there a reason these cannot be done in Mockito or EasyMock?
> >>>
> >>> --
> >>> Christopher L Tubbs II
> >>> http://gravatar.com/ctubbsii
> >>>
> >>>
> >>> On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com>
> >>> wrote:
> >>>
> >>>> -1
> >>>>
> >>>> I'm a little more invested in Mock since I wrote the first instance of
> >>>>
> >>> it.
> >>>
> >>>> I know it does not simulate the accumulo API perfectly. And I know
> it
> >>>> adds some maintenance overhead for anyone adding new features to the
> >>>> API.
> >>>>
> >>>> However, adding additional testing requirements for a new API is
> >>>>
> >>> something
> >>>
> >>>> I like.
> >>>>
> >>>> Take a counter example: the "file://" hdfs implementation. It allows
> >>>> you
> >>>> to use the local file system through the same API you would use for
> the
> >>>> distributed file system.
> >>>>
> >>>> Except, it doesn't. It does not behave the same as hdfs. None of our
> >>>> recovery tests can use the local fs implementation because it just
> >>>>
> >>> doesn't
> >>>
> >>>> implement the proper flush semantics.
> >>>>
> >>>> Yet dozens of our own tests rely on the speedy availability of the
> local
> >>>>
> >>> fs
> >>>
> >>>> implementation.
> >>>>
> >>>> Having a fast way to test iterators that uses a test harness is not
> the
> >>>> same thing as testing the iterators using the same API they would use
> >>>> without Mock. I have long called for an iterator test harness to
> stress
> >>>> the issues of iterator lifetimes.
> >>>>
> >>>> Finally, I would humbly suggest that our software has stabilized to
> the
> >>>> point where we tests at all levels:
> >>>>
> >>>> * iterator stress tester
> >>>> * Mock API
> >>>> * Integration test using MAC
> >>>> * System tests that can be run at full scale
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com>
> wrote:
> >>>>
> >>>> +1 for keeping a fast and easy (and well documented) mechanism for
> >>>>> debugging iterators. Perhaps the SortedMapiterator is the
> solution..but
> >>>>>
> >>>> the
> >>>
> >>>> key words here are 'well documented'
> >>>>>
> >>>>> -1 for continuing support a half implemented mock framework that we
> >>>>>
> >>>> have to
> >>>
> >>>> maintain. It makes code maintenance very hard when you couldnt, for
> >>>>> instance in the 1.3 series, even create a MockBatchDeleter. As Chris
> >>>>> stated, I agree that using the mock in the past had users walking the
> >>>>>
> >>>> line
> >>>
> >>>> too closely between unit and integration tests. With the mock, I could
> >>>>> write a bunch of fully valid tests against an iterator without the
> >>>>>
> >>>> ability
> >>>
> >>>> to verify that compactions didn't negatively affect my results. Except
> >>>>>
> >>>> for
> >>>
> >>>> being fast, the MAC mostly eliminates the need to use the mock for
> that
> >>>>> kind of test at all while it makes the tests more valid to an actual
> >>>>> runtime environment.
> >>>>>
> >>>>> +1 for mocking framework to be used in relevant unit tests. There are
> >>>>>
> >>>> times
> >>>
> >>>> when a quick and dirty mock is immensely useful and MAC is slow and
> way
> >>>>> overkill for those tasks. Perhaps it would be worth a ticket to
> >>>>>
> >>>> investigate
> >>>
> >>>> replacing the current usages of mockAccumulo (I haven't looked in
> >>>>>
> >>>> awhile)
> >>>
> >>>> with said mocking framework.
> >>>>>
> >>>>> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
> >>>>>
> >>>>>>
> >>>>>> +1 (not really a voter)
> >>>>>>
> >>>>>> I think iterator unit tests should use SortedMapIterator, not
> anything
> >>>>>>
> >>>>> like
> >>>>>
> >>>>>> a full accumulo stack, and I think MAC is far more suitable for
> >>>>>>
> >>>>> integration
> >>>>>
> >>>>>> tests because it actually runs the same code...it's impossible for
> an
> >>>>>> outsider to tell in which behaviors mock reflects actual accumulo
> and
> >>>>>>
> >>>>> in
> >>>
> >>>> which it does something totally different.
> >>>>>>
> >>>>>> I do think MAC needs some help, but I think the process of excising
> >>>>>>
> >>>>> mock
> >>>
> >>>> from our own tests will flesh out what we need there better than
> >>>>>>
> >>>>> anything
> >>>
> >>>> else we could do.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
> >>>>>>
> >>>>>> +1
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> *From:* Keith Turner [mailto:keith@deenlo.com]
> >>>>>>> *Sent:* Thursday, November 14, 2013 3:42 PM
> >>>>>>> *To:* dev@accumulo.apache.org; user@accumulo.apache.org
> >>>>>>> *Subject:* [VOTE] Deprecate mock in 1.6.0
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Should we deprecate mock accumulo for 1.6.0? This was considered
> >>>>>>>
> >>>>>> [1]
> >>>
> >>>> for
> >>>>>
> >>>>>> 1.5.0. I started thinking about this because I never added
> >>>>>>>
> >>>>>> conditional
> >>>
> >>>> writer to mock.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <jo...@gmail.com> wrote:
> I'll put the question out there:
>
> Is it an immediate non-starter to deprecate something that doesn't have an
> immediate replacement?
>
> 1. You can still use it even if it's deprecated (and our usage of
> deprecated typically falls under "we won't remove it before version X if
> not later")
> 2. We know there are problems with it.
> 3. We know we should be making other tools that better replace it (MAC) or
> just give you a specific piece of functionality (iterator smoke-test
> framework).
>
> Is this just my interpretation of how to interpret @Deprecated? It seems
> completely logical to deprecate something we know isn't where we want to go
> even if we aren't to where we want to go. Then, we start focusing on
> making/improving the tools we want. This advertises to users that maybe
> they might not want to rely on MockAccumulo.
I agree. I am thinking that if we do not maintain it, then its
deprecated whether we declare it or not. We at least 3 options :
1. Deprecate mock
2. Maintain mock (add new Accumulo features and actively fix bugs)
3. Leave it as is
I think we should choose 1 or 2, but not choose 3.
>
> On 11/18/13, 2:51 PM, Eric Newton wrote:
>
>> I had this basic interaction with a user today:
>>
>> "I upgraded my old-style Filter to the Filter-as-iterator-Filter, how do I
>> test it?"
>>
>> And the easiest thing to tell them was "use MockAccumulo". Without a
>> better answer, I'm not for deprecating Mock.
>>
>> I agree that there is considerable effort in trying to keep Mock
>> up-to-date, to the extent that I've not bothered to fix many of the
>> failings of Mock.
>>
>>
>>
>> On Mon, Nov 18, 2013 at 2:09 PM, Christopher <ct...@apache.org> wrote:
>>
>> Eric,
>>>
>>> Is there a reason these cannot be done in Mockito or EasyMock?
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>>
>>>
>>> On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com>
>>> wrote:
>>>
>>>> -1
>>>>
>>>> I'm a little more invested in Mock since I wrote the first instance of
>>>>
>>> it.
>>>
>>>> I know it does not simulate the accumulo API perfectly. And I know it
>>>> adds some maintenance overhead for anyone adding new features to the
>>>> API.
>>>>
>>>> However, adding additional testing requirements for a new API is
>>>>
>>> something
>>>
>>>> I like.
>>>>
>>>> Take a counter example: the "file://" hdfs implementation. It allows
>>>> you
>>>> to use the local file system through the same API you would use for the
>>>> distributed file system.
>>>>
>>>> Except, it doesn't. It does not behave the same as hdfs. None of our
>>>> recovery tests can use the local fs implementation because it just
>>>>
>>> doesn't
>>>
>>>> implement the proper flush semantics.
>>>>
>>>> Yet dozens of our own tests rely on the speedy availability of the local
>>>>
>>> fs
>>>
>>>> implementation.
>>>>
>>>> Having a fast way to test iterators that uses a test harness is not the
>>>> same thing as testing the iterators using the same API they would use
>>>> without Mock. I have long called for an iterator test harness to stress
>>>> the issues of iterator lifetimes.
>>>>
>>>> Finally, I would humbly suggest that our software has stabilized to the
>>>> point where we tests at all levels:
>>>>
>>>> * iterator stress tester
>>>> * Mock API
>>>> * Integration test using MAC
>>>> * System tests that can be run at full scale
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com> wrote:
>>>>
>>>> +1 for keeping a fast and easy (and well documented) mechanism for
>>>>> debugging iterators. Perhaps the SortedMapiterator is the solution..but
>>>>>
>>>> the
>>>
>>>> key words here are 'well documented'
>>>>>
>>>>> -1 for continuing support a half implemented mock framework that we
>>>>>
>>>> have to
>>>
>>>> maintain. It makes code maintenance very hard when you couldnt, for
>>>>> instance in the 1.3 series, even create a MockBatchDeleter. As Chris
>>>>> stated, I agree that using the mock in the past had users walking the
>>>>>
>>>> line
>>>
>>>> too closely between unit and integration tests. With the mock, I could
>>>>> write a bunch of fully valid tests against an iterator without the
>>>>>
>>>> ability
>>>
>>>> to verify that compactions didn't negatively affect my results. Except
>>>>>
>>>> for
>>>
>>>> being fast, the MAC mostly eliminates the need to use the mock for that
>>>>> kind of test at all while it makes the tests more valid to an actual
>>>>> runtime environment.
>>>>>
>>>>> +1 for mocking framework to be used in relevant unit tests. There are
>>>>>
>>>> times
>>>
>>>> when a quick and dirty mock is immensely useful and MAC is slow and way
>>>>> overkill for those tasks. Perhaps it would be worth a ticket to
>>>>>
>>>> investigate
>>>
>>>> replacing the current usages of mockAccumulo (I haven't looked in
>>>>>
>>>> awhile)
>>>
>>>> with said mocking framework.
>>>>>
>>>>> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
>>>>>
>>>>>>
>>>>>> +1 (not really a voter)
>>>>>>
>>>>>> I think iterator unit tests should use SortedMapIterator, not anything
>>>>>>
>>>>> like
>>>>>
>>>>>> a full accumulo stack, and I think MAC is far more suitable for
>>>>>>
>>>>> integration
>>>>>
>>>>>> tests because it actually runs the same code...it's impossible for an
>>>>>> outsider to tell in which behaviors mock reflects actual accumulo and
>>>>>>
>>>>> in
>>>
>>>> which it does something totally different.
>>>>>>
>>>>>> I do think MAC needs some help, but I think the process of excising
>>>>>>
>>>>> mock
>>>
>>>> from our own tests will flesh out what we need there better than
>>>>>>
>>>>> anything
>>>
>>>> else we could do.
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
>>>>>>
>>>>>> +1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* Keith Turner [mailto:keith@deenlo.com]
>>>>>>> *Sent:* Thursday, November 14, 2013 3:42 PM
>>>>>>> *To:* dev@accumulo.apache.org; user@accumulo.apache.org
>>>>>>> *Subject:* [VOTE] Deprecate mock in 1.6.0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Should we deprecate mock accumulo for 1.6.0? This was considered
>>>>>>>
>>>>>> [1]
>>>
>>>> for
>>>>>
>>>>>> 1.5.0. I started thinking about this because I never added
>>>>>>>
>>>>>> conditional
>>>
>>>> writer to mock.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>>>>>>
>>>>>>>
>>>>>
>>>
>>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Josh Elser <jo...@gmail.com>.
I'll put the question out there:
Is it an immediate non-starter to deprecate something that doesn't have
an immediate replacement?
1. You can still use it even if it's deprecated (and our usage of
deprecated typically falls under "we won't remove it before version X if
not later")
2. We know there are problems with it.
3. We know we should be making other tools that better replace it (MAC)
or just give you a specific piece of functionality (iterator smoke-test
framework).
Is this just my interpretation of how to interpret @Deprecated? It seems
completely logical to deprecate something we know isn't where we want to
go even if we aren't to where we want to go. Then, we start focusing on
making/improving the tools we want. This advertises to users that maybe
they might not want to rely on MockAccumulo.
On 11/18/13, 2:51 PM, Eric Newton wrote:
> I had this basic interaction with a user today:
>
> "I upgraded my old-style Filter to the Filter-as-iterator-Filter, how do I
> test it?"
>
> And the easiest thing to tell them was "use MockAccumulo". Without a
> better answer, I'm not for deprecating Mock.
>
> I agree that there is considerable effort in trying to keep Mock
> up-to-date, to the extent that I've not bothered to fix many of the
> failings of Mock.
>
>
>
> On Mon, Nov 18, 2013 at 2:09 PM, Christopher <ct...@apache.org> wrote:
>
>> Eric,
>>
>> Is there a reason these cannot be done in Mockito or EasyMock?
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com>
>> wrote:
>>> -1
>>>
>>> I'm a little more invested in Mock since I wrote the first instance of
>> it.
>>> I know it does not simulate the accumulo API perfectly. And I know it
>>> adds some maintenance overhead for anyone adding new features to the API.
>>>
>>> However, adding additional testing requirements for a new API is
>> something
>>> I like.
>>>
>>> Take a counter example: the "file://" hdfs implementation. It allows you
>>> to use the local file system through the same API you would use for the
>>> distributed file system.
>>>
>>> Except, it doesn't. It does not behave the same as hdfs. None of our
>>> recovery tests can use the local fs implementation because it just
>> doesn't
>>> implement the proper flush semantics.
>>>
>>> Yet dozens of our own tests rely on the speedy availability of the local
>> fs
>>> implementation.
>>>
>>> Having a fast way to test iterators that uses a test harness is not the
>>> same thing as testing the iterators using the same API they would use
>>> without Mock. I have long called for an iterator test harness to stress
>>> the issues of iterator lifetimes.
>>>
>>> Finally, I would humbly suggest that our software has stabilized to the
>>> point where we tests at all levels:
>>>
>>> * iterator stress tester
>>> * Mock API
>>> * Integration test using MAC
>>> * System tests that can be run at full scale
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com> wrote:
>>>
>>>> +1 for keeping a fast and easy (and well documented) mechanism for
>>>> debugging iterators. Perhaps the SortedMapiterator is the solution..but
>> the
>>>> key words here are 'well documented'
>>>>
>>>> -1 for continuing support a half implemented mock framework that we
>> have to
>>>> maintain. It makes code maintenance very hard when you couldnt, for
>>>> instance in the 1.3 series, even create a MockBatchDeleter. As Chris
>>>> stated, I agree that using the mock in the past had users walking the
>> line
>>>> too closely between unit and integration tests. With the mock, I could
>>>> write a bunch of fully valid tests against an iterator without the
>> ability
>>>> to verify that compactions didn't negatively affect my results. Except
>> for
>>>> being fast, the MAC mostly eliminates the need to use the mock for that
>>>> kind of test at all while it makes the tests more valid to an actual
>>>> runtime environment.
>>>>
>>>> +1 for mocking framework to be used in relevant unit tests. There are
>> times
>>>> when a quick and dirty mock is immensely useful and MAC is slow and way
>>>> overkill for those tasks. Perhaps it would be worth a ticket to
>> investigate
>>>> replacing the current usages of mockAccumulo (I haven't looked in
>> awhile)
>>>> with said mocking framework.
>>>>
>>>> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
>>>>>
>>>>> +1 (not really a voter)
>>>>>
>>>>> I think iterator unit tests should use SortedMapIterator, not anything
>>>> like
>>>>> a full accumulo stack, and I think MAC is far more suitable for
>>>> integration
>>>>> tests because it actually runs the same code...it's impossible for an
>>>>> outsider to tell in which behaviors mock reflects actual accumulo and
>> in
>>>>> which it does something totally different.
>>>>>
>>>>> I do think MAC needs some help, but I think the process of excising
>> mock
>>>>> from our own tests will flesh out what we need there better than
>> anything
>>>>> else we could do.
>>>>>
>>>>>
>>>>> On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Keith Turner [mailto:keith@deenlo.com]
>>>>>> *Sent:* Thursday, November 14, 2013 3:42 PM
>>>>>> *To:* dev@accumulo.apache.org; user@accumulo.apache.org
>>>>>> *Subject:* [VOTE] Deprecate mock in 1.6.0
>>>>>>
>>>>>>
>>>>>>
>>>>>> Should we deprecate mock accumulo for 1.6.0? This was considered
>> [1]
>>>> for
>>>>>> 1.5.0. I started thinking about this because I never added
>> conditional
>>>>>> writer to mock.
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>>>>>
>>>>
>>
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Eric Newton <er...@gmail.com>.
I had this basic interaction with a user today:
"I upgraded my old-style Filter to the Filter-as-iterator-Filter, how do I
test it?"
And the easiest thing to tell them was "use MockAccumulo". Without a
better answer, I'm not for deprecating Mock.
I agree that there is considerable effort in trying to keep Mock
up-to-date, to the extent that I've not bothered to fix many of the
failings of Mock.
On Mon, Nov 18, 2013 at 2:09 PM, Christopher <ct...@apache.org> wrote:
> Eric,
>
> Is there a reason these cannot be done in Mockito or EasyMock?
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com>
> wrote:
> > -1
> >
> > I'm a little more invested in Mock since I wrote the first instance of
> it.
> > I know it does not simulate the accumulo API perfectly. And I know it
> > adds some maintenance overhead for anyone adding new features to the API.
> >
> > However, adding additional testing requirements for a new API is
> something
> > I like.
> >
> > Take a counter example: the "file://" hdfs implementation. It allows you
> > to use the local file system through the same API you would use for the
> > distributed file system.
> >
> > Except, it doesn't. It does not behave the same as hdfs. None of our
> > recovery tests can use the local fs implementation because it just
> doesn't
> > implement the proper flush semantics.
> >
> > Yet dozens of our own tests rely on the speedy availability of the local
> fs
> > implementation.
> >
> > Having a fast way to test iterators that uses a test harness is not the
> > same thing as testing the iterators using the same API they would use
> > without Mock. I have long called for an iterator test harness to stress
> > the issues of iterator lifetimes.
> >
> > Finally, I would humbly suggest that our software has stabilized to the
> > point where we tests at all levels:
> >
> > * iterator stress tester
> > * Mock API
> > * Integration test using MAC
> > * System tests that can be run at full scale
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com> wrote:
> >
> >> +1 for keeping a fast and easy (and well documented) mechanism for
> >> debugging iterators. Perhaps the SortedMapiterator is the solution..but
> the
> >> key words here are 'well documented'
> >>
> >> -1 for continuing support a half implemented mock framework that we
> have to
> >> maintain. It makes code maintenance very hard when you couldnt, for
> >> instance in the 1.3 series, even create a MockBatchDeleter. As Chris
> >> stated, I agree that using the mock in the past had users walking the
> line
> >> too closely between unit and integration tests. With the mock, I could
> >> write a bunch of fully valid tests against an iterator without the
> ability
> >> to verify that compactions didn't negatively affect my results. Except
> for
> >> being fast, the MAC mostly eliminates the need to use the mock for that
> >> kind of test at all while it makes the tests more valid to an actual
> >> runtime environment.
> >>
> >> +1 for mocking framework to be used in relevant unit tests. There are
> times
> >> when a quick and dirty mock is immensely useful and MAC is slow and way
> >> overkill for those tasks. Perhaps it would be worth a ticket to
> investigate
> >> replacing the current usages of mockAccumulo (I haven't looked in
> awhile)
> >> with said mocking framework.
> >>
> >> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
> >> >
> >> > +1 (not really a voter)
> >> >
> >> > I think iterator unit tests should use SortedMapIterator, not anything
> >> like
> >> > a full accumulo stack, and I think MAC is far more suitable for
> >> integration
> >> > tests because it actually runs the same code...it's impossible for an
> >> > outsider to tell in which behaviors mock reflects actual accumulo and
> in
> >> > which it does something totally different.
> >> >
> >> > I do think MAC needs some help, but I think the process of excising
> mock
> >> > from our own tests will flesh out what we need there better than
> anything
> >> > else we could do.
> >> >
> >> >
> >> > On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
> >> >
> >> > > +1
> >> > >
> >> > >
> >> > >
> >> > > *From:* Keith Turner [mailto:keith@deenlo.com]
> >> > > *Sent:* Thursday, November 14, 2013 3:42 PM
> >> > > *To:* dev@accumulo.apache.org; user@accumulo.apache.org
> >> > > *Subject:* [VOTE] Deprecate mock in 1.6.0
> >> > >
> >> > >
> >> > >
> >> > > Should we deprecate mock accumulo for 1.6.0? This was considered
> [1]
> >> for
> >> > > 1.5.0. I started thinking about this because I never added
> conditional
> >> > > writer to mock.
> >> > >
> >> > >
> >> > >
> >> > > [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> >> > >
> >>
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Christopher <ct...@apache.org>.
Eric,
Is there a reason these cannot be done in Mockito or EasyMock?
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com> wrote:
> -1
>
> I'm a little more invested in Mock since I wrote the first instance of it.
> I know it does not simulate the accumulo API perfectly. And I know it
> adds some maintenance overhead for anyone adding new features to the API.
>
> However, adding additional testing requirements for a new API is something
> I like.
>
> Take a counter example: the "file://" hdfs implementation. It allows you
> to use the local file system through the same API you would use for the
> distributed file system.
>
> Except, it doesn't. It does not behave the same as hdfs. None of our
> recovery tests can use the local fs implementation because it just doesn't
> implement the proper flush semantics.
>
> Yet dozens of our own tests rely on the speedy availability of the local fs
> implementation.
>
> Having a fast way to test iterators that uses a test harness is not the
> same thing as testing the iterators using the same API they would use
> without Mock. I have long called for an iterator test harness to stress
> the issues of iterator lifetimes.
>
> Finally, I would humbly suggest that our software has stabilized to the
> point where we tests at all levels:
>
> * iterator stress tester
> * Mock API
> * Integration test using MAC
> * System tests that can be run at full scale
>
>
>
>
>
>
>
> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com> wrote:
>
>> +1 for keeping a fast and easy (and well documented) mechanism for
>> debugging iterators. Perhaps the SortedMapiterator is the solution..but the
>> key words here are 'well documented'
>>
>> -1 for continuing support a half implemented mock framework that we have to
>> maintain. It makes code maintenance very hard when you couldnt, for
>> instance in the 1.3 series, even create a MockBatchDeleter. As Chris
>> stated, I agree that using the mock in the past had users walking the line
>> too closely between unit and integration tests. With the mock, I could
>> write a bunch of fully valid tests against an iterator without the ability
>> to verify that compactions didn't negatively affect my results. Except for
>> being fast, the MAC mostly eliminates the need to use the mock for that
>> kind of test at all while it makes the tests more valid to an actual
>> runtime environment.
>>
>> +1 for mocking framework to be used in relevant unit tests. There are times
>> when a quick and dirty mock is immensely useful and MAC is slow and way
>> overkill for those tasks. Perhaps it would be worth a ticket to investigate
>> replacing the current usages of mockAccumulo (I haven't looked in awhile)
>> with said mocking framework.
>>
>> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
>> >
>> > +1 (not really a voter)
>> >
>> > I think iterator unit tests should use SortedMapIterator, not anything
>> like
>> > a full accumulo stack, and I think MAC is far more suitable for
>> integration
>> > tests because it actually runs the same code...it's impossible for an
>> > outsider to tell in which behaviors mock reflects actual accumulo and in
>> > which it does something totally different.
>> >
>> > I do think MAC needs some help, but I think the process of excising mock
>> > from our own tests will flesh out what we need there better than anything
>> > else we could do.
>> >
>> >
>> > On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
>> >
>> > > +1
>> > >
>> > >
>> > >
>> > > *From:* Keith Turner [mailto:keith@deenlo.com]
>> > > *Sent:* Thursday, November 14, 2013 3:42 PM
>> > > *To:* dev@accumulo.apache.org; user@accumulo.apache.org
>> > > *Subject:* [VOTE] Deprecate mock in 1.6.0
>> > >
>> > >
>> > >
>> > > Should we deprecate mock accumulo for 1.6.0? This was considered [1]
>> for
>> > > 1.5.0. I started thinking about this because I never added conditional
>> > > writer to mock.
>> > >
>> > >
>> > >
>> > > [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>> > >
>>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Keith Turner <ke...@deenlo.com>.
On Sun, Nov 17, 2013 at 7:22 PM, Eric Newton <er...@gmail.com> wrote:
> -1
>
> I'm a little more invested in Mock since I wrote the first instance of it.
> I know it does not simulate the accumulo API perfectly. And I know it
> adds some maintenance overhead for anyone adding new features to the API.
>
> However, adding additional testing requirements for a new API is something
> I like.
>
> Take a counter example: the "file://" hdfs implementation. It allows you
> to use the local file system through the same API you would use for the
> distributed file system.
>
> Except, it doesn't. It does not behave the same as hdfs. None of our
> recovery tests can use the local fs implementation because it just doesn't
> implement the proper flush semantics.
>
I think Hadoop should fix local fs to have correct behavior. Just like we
should fix Mock to have correct behavior if we are going to continue to
maintain it.
>
> Yet dozens of our own tests rely on the speedy availability of the local fs
> implementation.
>
> Having a fast way to test iterators that uses a test harness is not the
> same thing as testing the iterators using the same API they would use
> without Mock. I have long called for an iterator test harness to stress
> the issues of iterator lifetimes.
>
> Finally, I would humbly suggest that our software has stabilized to the
> point where we tests at all levels:
>
> * iterator stress tester
> * Mock API
> * Integration test using MAC
> * System tests that can be run at full scale
>
>
>
>
>
>
>
> On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com> wrote:
>
> > +1 for keeping a fast and easy (and well documented) mechanism for
> > debugging iterators. Perhaps the SortedMapiterator is the solution..but
> the
> > key words here are 'well documented'
> >
> > -1 for continuing support a half implemented mock framework that we have
> to
> > maintain. It makes code maintenance very hard when you couldnt, for
> > instance in the 1.3 series, even create a MockBatchDeleter. As Chris
> > stated, I agree that using the mock in the past had users walking the
> line
> > too closely between unit and integration tests. With the mock, I could
> > write a bunch of fully valid tests against an iterator without the
> ability
> > to verify that compactions didn't negatively affect my results. Except
> for
> > being fast, the MAC mostly eliminates the need to use the mock for that
> > kind of test at all while it makes the tests more valid to an actual
> > runtime environment.
> >
> > +1 for mocking framework to be used in relevant unit tests. There are
> times
> > when a quick and dirty mock is immensely useful and MAC is slow and way
> > overkill for those tasks. Perhaps it would be worth a ticket to
> investigate
> > replacing the current usages of mockAccumulo (I haven't looked in awhile)
> > with said mocking framework.
> >
> > On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
> > >
> > > +1 (not really a voter)
> > >
> > > I think iterator unit tests should use SortedMapIterator, not anything
> > like
> > > a full accumulo stack, and I think MAC is far more suitable for
> > integration
> > > tests because it actually runs the same code...it's impossible for an
> > > outsider to tell in which behaviors mock reflects actual accumulo and
> in
> > > which it does something totally different.
> > >
> > > I do think MAC needs some help, but I think the process of excising
> mock
> > > from our own tests will flesh out what we need there better than
> anything
> > > else we could do.
> > >
> > >
> > > On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
> > >
> > > > +1
> > > >
> > > >
> > > >
> > > > *From:* Keith Turner [mailto:keith@deenlo.com]
> > > > *Sent:* Thursday, November 14, 2013 3:42 PM
> > > > *To:* dev@accumulo.apache.org; user@accumulo.apache.org
> > > > *Subject:* [VOTE] Deprecate mock in 1.6.0
> > > >
> > > >
> > > >
> > > > Should we deprecate mock accumulo for 1.6.0? This was considered [1]
> > for
> > > > 1.5.0. I started thinking about this because I never added
> conditional
> > > > writer to mock.
> > > >
> > > >
> > > >
> > > > [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> > > >
> >
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Eric Newton <er...@gmail.com>.
-1
I'm a little more invested in Mock since I wrote the first instance of it.
I know it does not simulate the accumulo API perfectly. And I know it
adds some maintenance overhead for anyone adding new features to the API.
However, adding additional testing requirements for a new API is something
I like.
Take a counter example: the "file://" hdfs implementation. It allows you
to use the local file system through the same API you would use for the
distributed file system.
Except, it doesn't. It does not behave the same as hdfs. None of our
recovery tests can use the local fs implementation because it just doesn't
implement the proper flush semantics.
Yet dozens of our own tests rely on the speedy availability of the local fs
implementation.
Having a fast way to test iterators that uses a test harness is not the
same thing as testing the iterators using the same API they would use
without Mock. I have long called for an iterator test harness to stress
the issues of iterator lifetimes.
Finally, I would humbly suggest that our software has stabilized to the
point where we tests at all levels:
* iterator stress tester
* Mock API
* Integration test using MAC
* System tests that can be run at full scale
On Sat, Nov 16, 2013 at 1:12 PM, Corey Nolet <cj...@gmail.com> wrote:
> +1 for keeping a fast and easy (and well documented) mechanism for
> debugging iterators. Perhaps the SortedMapiterator is the solution..but the
> key words here are 'well documented'
>
> -1 for continuing support a half implemented mock framework that we have to
> maintain. It makes code maintenance very hard when you couldnt, for
> instance in the 1.3 series, even create a MockBatchDeleter. As Chris
> stated, I agree that using the mock in the past had users walking the line
> too closely between unit and integration tests. With the mock, I could
> write a bunch of fully valid tests against an iterator without the ability
> to verify that compactions didn't negatively affect my results. Except for
> being fast, the MAC mostly eliminates the need to use the mock for that
> kind of test at all while it makes the tests more valid to an actual
> runtime environment.
>
> +1 for mocking framework to be used in relevant unit tests. There are times
> when a quick and dirty mock is immensely useful and MAC is slow and way
> overkill for those tasks. Perhaps it would be worth a ticket to investigate
> replacing the current usages of mockAccumulo (I haven't looked in awhile)
> with said mocking framework.
>
> On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
> >
> > +1 (not really a voter)
> >
> > I think iterator unit tests should use SortedMapIterator, not anything
> like
> > a full accumulo stack, and I think MAC is far more suitable for
> integration
> > tests because it actually runs the same code...it's impossible for an
> > outsider to tell in which behaviors mock reflects actual accumulo and in
> > which it does something totally different.
> >
> > I do think MAC needs some help, but I think the process of excising mock
> > from our own tests will flesh out what we need there better than anything
> > else we could do.
> >
> >
> > On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
> >
> > > +1
> > >
> > >
> > >
> > > *From:* Keith Turner [mailto:keith@deenlo.com]
> > > *Sent:* Thursday, November 14, 2013 3:42 PM
> > > *To:* dev@accumulo.apache.org; user@accumulo.apache.org
> > > *Subject:* [VOTE] Deprecate mock in 1.6.0
> > >
> > >
> > >
> > > Should we deprecate mock accumulo for 1.6.0? This was considered [1]
> for
> > > 1.5.0. I started thinking about this because I never added conditional
> > > writer to mock.
> > >
> > >
> > >
> > > [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> > >
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Corey Nolet <cj...@gmail.com>.
+1 for keeping a fast and easy (and well documented) mechanism for
debugging iterators. Perhaps the SortedMapiterator is the solution..but the
key words here are 'well documented'
-1 for continuing support a half implemented mock framework that we have to
maintain. It makes code maintenance very hard when you couldnt, for
instance in the 1.3 series, even create a MockBatchDeleter. As Chris
stated, I agree that using the mock in the past had users walking the line
too closely between unit and integration tests. With the mock, I could
write a bunch of fully valid tests against an iterator without the ability
to verify that compactions didn't negatively affect my results. Except for
being fast, the MAC mostly eliminates the need to use the mock for that
kind of test at all while it makes the tests more valid to an actual
runtime environment.
+1 for mocking framework to be used in relevant unit tests. There are times
when a quick and dirty mock is immensely useful and MAC is slow and way
overkill for those tasks. Perhaps it would be worth a ticket to investigate
replacing the current usages of mockAccumulo (I haven't looked in awhile)
with said mocking framework.
On Nov 15, 2013 3:29 PM, "Michael Berman" <mb...@sqrrl.com> wrote:
>
> +1 (not really a voter)
>
> I think iterator unit tests should use SortedMapIterator, not anything
like
> a full accumulo stack, and I think MAC is far more suitable for
integration
> tests because it actually runs the same code...it's impossible for an
> outsider to tell in which behaviors mock reflects actual accumulo and in
> which it does something totally different.
>
> I do think MAC needs some help, but I think the process of excising mock
> from our own tests will flesh out what we need there better than anything
> else we could do.
>
>
> On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
>
> > +1
> >
> >
> >
> > *From:* Keith Turner [mailto:keith@deenlo.com]
> > *Sent:* Thursday, November 14, 2013 3:42 PM
> > *To:* dev@accumulo.apache.org; user@accumulo.apache.org
> > *Subject:* [VOTE] Deprecate mock in 1.6.0
> >
> >
> >
> > Should we deprecate mock accumulo for 1.6.0? This was considered [1]
for
> > 1.5.0. I started thinking about this because I never added conditional
> > writer to mock.
> >
> >
> >
> > [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> >
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Michael Berman <mb...@sqrrl.com>.
+1 (not really a voter)
I think iterator unit tests should use SortedMapIterator, not anything like
a full accumulo stack, and I think MAC is far more suitable for integration
tests because it actually runs the same code...it's impossible for an
outsider to tell in which behaviors mock reflects actual accumulo and in
which it does something totally different.
I do think MAC needs some help, but I think the process of excising mock
from our own tests will flesh out what we need there better than anything
else we could do.
On Thu, Nov 14, 2013 at 9:20 PM, <dl...@comcast.net> wrote:
> +1
>
>
>
> *From:* Keith Turner [mailto:keith@deenlo.com]
> *Sent:* Thursday, November 14, 2013 3:42 PM
> *To:* dev@accumulo.apache.org; user@accumulo.apache.org
> *Subject:* [VOTE] Deprecate mock in 1.6.0
>
>
>
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
>
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>
RE: [VOTE] Deprecate mock in 1.6.0
Posted by dl...@comcast.net.
+1
From: Keith Turner [mailto:keith@deenlo.com]
Sent: Thursday, November 14, 2013 3:42 PM
To: dev@accumulo.apache.org; user@accumulo.apache.org
Subject: [VOTE] Deprecate mock in 1.6.0
Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
1.5.0. I started thinking about this because I never added conditional
writer to mock.
[1] : https://issues.apache.org/jira/browse/ACCUMULO-878
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Keith Turner <ke...@deenlo.com>.
On Thu, Nov 14, 2013 at 3:47 PM, Sean Busbey <bu...@clouderagovt.com>wrote:
> On Thu, Nov 14, 2013 at 2:41 PM, Keith Turner <ke...@deenlo.com> wrote:
>
>> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
>> 1.5.0. I started thinking about this because I never added conditional
>> writer to mock.
>>
>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>
>
>
> Would deprecating it in 1.6.0 mean it is removed in 1.7.0 or in 1.8.0?
>
We do not have a good policy for deciding when deprecated things will be
removed. I was looking at some other Java project today that declared
when deprecated methods would be removed.
>
> Does it impact anything else? Would we not attempt feature parity for
> 1.6.0 (e.g. conditional writer)?
>
Thats what I was thinking. If its deprecated then there is no need to add
conditional writer support.
>
>
> --
> Sean
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Sean Busbey <bu...@clouderagovt.com>.
On Thu, Nov 14, 2013 at 2:41 PM, Keith Turner <ke...@deenlo.com> wrote:
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>
Would deprecating it in 1.6.0 mean it is removed in 1.7.0 or in 1.8.0?
Does it impact anything else? Would we not attempt feature parity for 1.6.0
(e.g. conditional writer)?
--
Sean
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Christopher <ct...@apache.org>.
+1
I'd prefer we get a bit more rigorous about the distinction between
integration testing and unit testing. MockAccumulo walks that line too
closely, and I think it encourages writing bad tests, with the risk
that code relies on incorrect mock behavior.
I'd prefer to put some effort into making the accumulo-maven-plugin
more robust and feature-ful for actual integration testing. In the
meantime, raw MiniAccumuloCluster is suitable for ITs. For actual unit
tests, we should encourage the use of EasyMock or Mockito or something
like that, and stop trying to test end-to-end behavior in unit tests.
To unit test iterators, there's already a SortedMapIterator that
allows you to create an iterator from a TreeMap.
I don't think we should remove it anytime soon, but we should
deprecate it. The sooner we deprecate it, the less burden we have to
maintain two implementations of every new feature, and the more time
we'll have to spend time on improving the tests in other ways.
MiniAccumuloCluster can do everything that MockAccumulo can do. The
fact that it doesn't run as fast is not a good enough reason, in my
opinion, to avoid deprecating it... especially since the test cases
where it is being used (where the performance matters) blur the lines
between unit tests and integration tests... and that tends to hurt us
in terms of code coverage and test reliability.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Thu, Nov 14, 2013 at 3:41 PM, Keith Turner <ke...@deenlo.com> wrote:
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Keith Turner <ke...@deenlo.com>.
+1
On Thu, Nov 14, 2013 at 3:41 PM, Keith Turner <ke...@deenlo.com> wrote:
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Billie Rinaldi <bi...@apache.org>.
+1
On Nov 14, 2013 3:42 PM, "Keith Turner" <ke...@deenlo.com> wrote:
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Bill Havanki <bh...@clouderagovt.com>.
+1 (non-binding)
Christopher's comment on -878 [1] echoes my thinking. For me, "mock" means
"unit tests", and I'd rather use a mock framework (Easymock, Mockito,
whatever) than a running cluster (however lightweight) in unit tests.
[1]:
https://issues.apache.org/jira/browse/ACCUMULO-878?focusedCommentId=13504949&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13504949
On Thu, Nov 14, 2013 at 3:41 PM, Keith Turner <ke...@deenlo.com> wrote:
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>
--
| - - -
| Bill Havanki
| Solutions Architect, Cloudera Government Solutions
| - - -
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Sean Busbey <bu...@clouderagovt.com>.
On Thu, Nov 14, 2013 at 2:41 PM, Keith Turner <ke...@deenlo.com> wrote:
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>
Would deprecating it in 1.6.0 mean it is removed in 1.7.0 or in 1.8.0?
Does it impact anything else? Would we not attempt feature parity for 1.6.0
(e.g. conditional writer)?
--
Sean
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Keith Turner <ke...@deenlo.com>.
+1
On Thu, Nov 14, 2013 at 3:41 PM, Keith Turner <ke...@deenlo.com> wrote:
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by John Vines <vi...@apache.org>.
Sent from my phone, please pardon the typos and brevity.
On Nov 14, 2013 2:49 PM, "Josh Elser" <jo...@gmail.com> wrote:
>
> +1
>
> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd
rather see effort placed into making MAC a reliable and fast testing
mechanism than helping Mock limp along
-1
We do not have a suitable alternative in place in 1.6 and I don't think we
should deprecate it until there is one.
>
>
> On 11/14/13, 12:41 PM, Keith Turner wrote:
>>
>> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
>> 1.5.0. I started thinking about this because I never added conditional
>> writer to mock.
>>
>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by John Vines <vi...@apache.org>.
Sent from my phone, please pardon the typos and brevity.
On Nov 14, 2013 2:49 PM, "Josh Elser" <jo...@gmail.com> wrote:
>
> +1
>
> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd
rather see effort placed into making MAC a reliable and fast testing
mechanism than helping Mock limp along
-1
We do not have a suitable alternative in place in 1.6 and I don't think we
should deprecate it until there is one.
>
>
> On 11/14/13, 12:41 PM, Keith Turner wrote:
>>
>> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
>> 1.5.0. I started thinking about this because I never added conditional
>> writer to mock.
>>
>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by David Medinets <da...@gmail.com>.
+0 - what's the number if I'm undecided? I'd prefer to see one uber-cool
one testing mechanism instead of multiples.
On Thu, Nov 14, 2013 at 5:54 PM, John Vines <vi...@apache.org> wrote:
> Sent from my phone, please pardon the typos and brevity.
> On Nov 14, 2013 4:46 PM, "Josh Elser" <jo...@gmail.com> wrote:
> >
> > On 11/14/13, 2:41 PM, John Vines wrote:
> >>
> >> Sent from my phone, please pardon the typos and brevity.
> >> On Nov 14, 2013 2:49 PM, "Josh Elser" <jo...@gmail.com> wrote:
> >>>
> >>>
> >>> +1
> >>>
> >>> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd
> >>
> >> rather see effort placed into making MAC a reliable and fast testing
> >> mechanism than helping Mock limp along
> >>
> >> -1
> >>
> >> MAC isn't there yet and I don't think we should deprecate it without a
> >> suitable alternative in place
> >
> >
> > Can you provide why you think "MAC isn't there yet" and what you would
> consider the bar for "suitable alternative" please?
>
> Faster to use, easier to use in junit tests, and easier to debug iterators
> in an ide.
>
> Specifically, the spin up time of mock vs Mac is orders of magnitude.
> Because of that, junit tests should reuse a mock, which I think the maven
> plugin should help with, but I don't know how well it works and what the
> effect is on in IDE testing. Lastly, because tservers spin up in new
> processes, it makes it overwhelmingly difficult to debug an iterator stack.
> Either mechanisms to improve debug hooks for the processes or an
> alternative iterator testing suite is in order.
>
> >
> >
> >>>
> >>>
> >>> On 11/14/13, 12:41 PM, Keith Turner wrote:
> >>>>
> >>>>
> >>>> Should we deprecate mock accumulo for 1.6.0? This was considered [1]
> for
> >>>> 1.5.0. I started thinking about this because I never added
> conditional
> >>>> writer to mock.
> >>>>
> >>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> >>>>
> >>
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Keith Turner <ke...@deenlo.com>.
On Thu, Nov 14, 2013 at 5:54 PM, John Vines <vi...@apache.org> wrote:
> Sent from my phone, please pardon the typos and brevity.
> On Nov 14, 2013 4:46 PM, "Josh Elser" <jo...@gmail.com> wrote:
> >
> > On 11/14/13, 2:41 PM, John Vines wrote:
> >>
> >> Sent from my phone, please pardon the typos and brevity.
> >> On Nov 14, 2013 2:49 PM, "Josh Elser" <jo...@gmail.com> wrote:
> >>>
> >>>
> >>> +1
> >>>
> >>> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd
> >>
> >> rather see effort placed into making MAC a reliable and fast testing
> >> mechanism than helping Mock limp along
> >>
> >> -1
> >>
> >> MAC isn't there yet and I don't think we should deprecate it without a
> >> suitable alternative in place
> >
> >
> > Can you provide why you think "MAC isn't there yet" and what you would
> consider the bar for "suitable alternative" please?
>
> Faster to use, easier to use in junit tests, and easier to debug iterators
> in an ide.
>
> Specifically, the spin up time of mock vs Mac is orders of magnitude.
> Because of that, junit tests should reuse a mock, which I think the maven
> plugin should help with, but I don't know how well it works and what the
> effect is on in IDE testing. Lastly, because tservers spin up in new
> processes, it makes it overwhelmingly difficult to debug an iterator stack.
> Either mechanisms to improve debug hooks for the processes or an
> alternative iterator testing suite is in order.
>
This is a really good point. What about making the deprecation javadoc
point to SortedMapIterator?
>
> >
> >
> >>>
> >>>
> >>> On 11/14/13, 12:41 PM, Keith Turner wrote:
> >>>>
> >>>>
> >>>> Should we deprecate mock accumulo for 1.6.0? This was considered [1]
> for
> >>>> 1.5.0. I started thinking about this because I never added
> conditional
> >>>> writer to mock.
> >>>>
> >>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
> >>>>
> >>
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by John Vines <vi...@apache.org>.
Sent from my phone, please pardon the typos and brevity.
On Nov 14, 2013 4:46 PM, "Josh Elser" <jo...@gmail.com> wrote:
>
> On 11/14/13, 2:41 PM, John Vines wrote:
>>
>> Sent from my phone, please pardon the typos and brevity.
>> On Nov 14, 2013 2:49 PM, "Josh Elser" <jo...@gmail.com> wrote:
>>>
>>>
>>> +1
>>>
>>> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd
>>
>> rather see effort placed into making MAC a reliable and fast testing
>> mechanism than helping Mock limp along
>>
>> -1
>>
>> MAC isn't there yet and I don't think we should deprecate it without a
>> suitable alternative in place
>
>
> Can you provide why you think "MAC isn't there yet" and what you would
consider the bar for "suitable alternative" please?
Faster to use, easier to use in junit tests, and easier to debug iterators
in an ide.
Specifically, the spin up time of mock vs Mac is orders of magnitude.
Because of that, junit tests should reuse a mock, which I think the maven
plugin should help with, but I don't know how well it works and what the
effect is on in IDE testing. Lastly, because tservers spin up in new
processes, it makes it overwhelmingly difficult to debug an iterator stack.
Either mechanisms to improve debug hooks for the processes or an
alternative iterator testing suite is in order.
>
>
>>>
>>>
>>> On 11/14/13, 12:41 PM, Keith Turner wrote:
>>>>
>>>>
>>>> Should we deprecate mock accumulo for 1.6.0? This was considered [1]
for
>>>> 1.5.0. I started thinking about this because I never added conditional
>>>> writer to mock.
>>>>
>>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>>>
>>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Josh Elser <jo...@gmail.com>.
On 11/14/13, 2:41 PM, John Vines wrote:
> Sent from my phone, please pardon the typos and brevity.
> On Nov 14, 2013 2:49 PM, "Josh Elser" <jo...@gmail.com> wrote:
>>
>> +1
>>
>> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd
> rather see effort placed into making MAC a reliable and fast testing
> mechanism than helping Mock limp along
>
> -1
>
> MAC isn't there yet and I don't think we should deprecate it without a
> suitable alternative in place
Can you provide why you think "MAC isn't there yet" and what you would
consider the bar for "suitable alternative" please?
>>
>>
>> On 11/14/13, 12:41 PM, Keith Turner wrote:
>>>
>>> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
>>> 1.5.0. I started thinking about this because I never added conditional
>>> writer to mock.
>>>
>>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>>
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by John Vines <jv...@gmail.com>.
Sent from my phone, please pardon the typos and brevity.
On Nov 14, 2013 2:49 PM, "Josh Elser" <jo...@gmail.com> wrote:
>
> +1
>
> Been bitten by goofy/half-implemented stuff in Mock too many times. I'd
rather see effort placed into making MAC a reliable and fast testing
mechanism than helping Mock limp along
-1
MAC isn't there yet and I don't think we should deprecate it without a
suitable alternative in place
>
>
> On 11/14/13, 12:41 PM, Keith Turner wrote:
>>
>> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
>> 1.5.0. I started thinking about this because I never added conditional
>> writer to mock.
>>
>> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Josh Elser <jo...@gmail.com>.
+1
Been bitten by goofy/half-implemented stuff in Mock too many times. I'd
rather see effort placed into making MAC a reliable and fast testing
mechanism than helping Mock limp along
On 11/14/13, 12:41 PM, Keith Turner wrote:
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>
Re: [VOTE] Deprecate mock in 1.6.0
Posted by Josh Elser <jo...@gmail.com>.
+1
Been bitten by goofy/half-implemented stuff in Mock too many times. I'd
rather see effort placed into making MAC a reliable and fast testing
mechanism than helping Mock limp along
On 11/14/13, 12:41 PM, Keith Turner wrote:
> Should we deprecate mock accumulo for 1.6.0? This was considered [1] for
> 1.5.0. I started thinking about this because I never added conditional
> writer to mock.
>
> [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
>