Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> [VOTE] Deprecate mock in 1.6.0


Copy link to this message
-
Re: [VOTE] Deprecate mock in 1.6.0
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 <[EMAIL PROTECTED]> wrote:

> On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> >>> 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB