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 <[email protected]> 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 <[email protected]>
wrote:
On Mon, Nov 18, 2013 at 4:26 PM, Christopher <[email protected]>
wrote:
On Mon, Nov 18, 2013 at 3:02 PM, Josh Elser <[email protected]>
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
