Re: accumulo Scanner

You're going to want to use WholeRowIterator.decodeRow(entry.getKey(), entry.getValue()) for that one. You can do: for(Entry entry : scanner) { for(Entry actualEntry : WholeRowIterator.decodeRow(entry.getKey(), entry.getValue()).entrySet()) { // do something with actualEntry } } On

Re: accumulo Scanner

I try to use the WholeRowIterator, the same rowkey data into a line, Now, Value contains ColumnFamily, ColumnQualifier, value，but the value of Value should be how to analysis? for (Entry entry : scanner) { log.info("" + entry.getKey() + "," + entry.getValue()); } -- View

Re: Official Guidance to users regarding removal of functions

Great, thanks for the feedback. I just committed this in ACCUMULO-3403 Christopher wrote: Yes, I agree you should just reintroduce the method if it was removed in 1.7, which is not yet released. If it was removed in 1.6.{0,1}, you could also consider reintroducing it for 1.6.2, to support those

Re: Official Guidance to users regarding removal of functions

Yes, I agree you should just reintroduce the method if it was removed in 1.7, which is not yet released. If it was removed in 1.6.{0,1}, you could also consider reintroducing it for 1.6.2, to support those users also. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Dec 11, 2014 at

Re: Official Guidance to users regarding removal of functions

For context and as a good example of how we could be less abrasive, I'm unexpectedly spending today updating Hive with a bunch of new reflection because methods in 1.5 on AccumuloInputFormat no longer exist in 1.7. setZooKeeperInstance used to take two Strings, but in 1.7 this version of the me

Re: Official Guidance to users regarding removal of functions

FWIW, Java 9 is dropping methods for the first time that the JDK API is dropping methods. Almost 20 years. Just something to consider, when we approach the conversation of how long to keep APIs around. On Thu, Dec 11, 2014 at 3:46 PM, Christopher wrote: > You seem to be dismissing "clean up" as

Re: Official Guidance to users regarding removal of functions

You seem to be dismissing "clean up" as an invalid. I disagree. There are costs to keeping around deprecated APIs. That's not to say we shouldn't keep them around for a long time... we can and perhaps should. But "clean up" is just shorthand for all the maintainability, readability, and usability c

Re: Official Guidance to users regarding removal of functions

In addition to the responses already provided, I think it'd be better to just continue supporting 1.x with new features/bugfixes as long as there is demand for it, would be preferred than trying to keep a 1.x shim API on top of newer releases. -- Christopher L Tubbs II http://gravatar.com/ctubbsi

Re: Official Guidance to users regarding removal of functions

On Thu, Dec 11, 2014 at 2:19 PM, Kepner, Jeremy - 0553 - MITLL < kep...@ll.mit.edu> wrote: > So I think the bigger issue is to revisit the imperative to delete > deprecated functions (both public & private). How many instances have we > had where deleting a deprecated API (public & private) did a

Re: Official Guidance to users regarding removal of functions

So I think the bigger issue is to revisit the imperative to delete deprecated functions (both public & private). How many instances have we had where deleting a deprecated API (public & private) did anything more than "clean up" the code? On Dec 11, 2014, at 2:39 PM, John Vines wrote: > More

Re: Official Guidance to users regarding removal of functions

More likely we'd have a fully backwards compatible API for each major version. SemVer allows for it and I think that grants us enough room for growth while still securing things for future releases. On Thu, Dec 11, 2014 at 2:36 PM, Adam Fuchs wrote: > Awesome -- ACCUMULO-2589 gets us at least ha

Re: Official Guidance to users regarding removal of functions

Awesome -- ACCUMULO-2589 gets us at least halfway there. Given this, what would be the challenges in having and maintaining one API project for each major version ever released? Adam On Thu, Dec 11, 2014 at 2:24 PM, Josh Elser wrote: > Adam Fuchs wrote: >> >> Has anybody looked into separating t

Re: Official Guidance to users regarding removal of functions

Adam Fuchs wrote: Has anybody looked into separating the public API a bit more from the core? It seems to me that a large number of the deprecation removal issues are related to people failing to read section 9 of the README. It would be great if we built an API jar that people could build agains

Re: Official Guidance to users regarding removal of functions

Has anybody looked into separating the public API a bit more from the core? It seems to me that a large number of the deprecation removal issues are related to people failing to read section 9 of the README. It would be great if we built an API jar that people could build against, but didn't leak i

Re: Official Guidance to users regarding removal of functions

So the simple solution is to deprecate often, but remove almost never. It is very rare that leaving a deprecated API in place actually has a negative impact. The code gets a little less clean, but that's fine as long as things are clearly labeled as deprecated. In fact, seeing the way something u

Re: Review Request 28873: ACCUMULO-3393 Follow-on work for per-table volume chooser.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28873/#review64763 --- Ship it! Current implementation looks pretty good. Small issue wit

Re: Official Guidance to users regarding removal of functions

I don't know that it'd be "cold comfort". We can continue to support 1.x for some time, if we choose. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Dec 11, 2014 at 12:53 PM, Billie Rinaldi wrote: > Actually, I wasn't suggesting anything. I was providing elaboration on > what

Re: Official Guidance to users regarding removal of functions

Actually, I wasn't suggesting anything. I was providing elaboration on what John was referring to. I imagine that stronger API guarantees will be cold comfort in the face of a 1.0 -> 2.0 upgrade. However, if we had been using semver all along, there would have been much less pain for users in th

Re: Official Guidance to users regarding removal of functions

On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL < kep...@ll.mit.edu> wrote: > When we remove functions, do we have any official guidance to our users > who may have built applications that use those functions? > > I assume by "functions", you mean API, not functionality. To my know

Re: Official Guidance to users regarding removal of functions

On Thu, Dec 11, 2014 at 12:11 PM, Mike Drob wrote: > Billie, > > Not to be glib, but it reads like your suggestion to Jeremy for when we > have a 2.0.0 release (assuming semver passes) is to take option (2) Don't > upgrade Accumulo. > > Please correct my misunderstanding. > That is perfectly fi

Re: Official Guidance to users regarding removal of functions

Billie, Not to be glib, but it reads like your suggestion to Jeremy for when we have a 2.0.0 release (assuming semver passes) is to take option (2) Don't upgrade Accumulo. Please correct my misunderstanding. Mike On Thu, Dec 11, 2014 at 11:07 AM, Billie Rinaldi wrote: > To clarify John's ques

Re: Official Guidance to users regarding removal of functions

To clarify John's question: if our vote to adopt semver 2.0.0 passes, our intention will be to no longer have breaking public API changes unless the major version number is incremented, i.e. 1.x.x -> 2.x.x. An important aspect of semantic versioning is defining what is considered part of the public

Re: Official Guidance to users regarding removal of functions

Jeremy, It is my understanding that our practice is to flag to-be-removed API components with Deprecation annotations and a note for the replacement. That notice should be around for a full major version[1], though obviously that's of limited utility if the lifespan of the major release is short.

Re: Official Guidance to users regarding removal of functions

How do you see this as different from any other major open source platform? Every one I've ever worked on does deprecate and remove things; generally deprecation is accompanied by comments and release notes offering adaptation advice. On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MIT

Re: Official Guidance to users regarding removal of functions

Wouldn't this be resolved with our SemVer sqwitch? On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL < kep...@ll.mit.edu> wrote: > When we remove functions, do we have any official guidance to our users > who may have built applications that use those functions? > > Right now, the o

Official Guidance to users regarding removal of functions

When we remove functions, do we have any official guidance to our users who may have built applications that use those functions? Right now, the official position is that the Accumulo developers can remove based on a consensus vote. However, this provides no guidance to users as to what they ar

Re: Google analytics summaries

I'm for it. Also, does anyone know how I get access to the google analytics reports page for our site? Thanks, Adam On Thu, Dec 11, 2014 at 11:14 AM, Sean Busbey wrote: > I just got the mail summary of our google analytics stats for > accumulo.apache.org. > > Anyone opposed to me starting to f

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

I think we crossed the streams. I'll talk to you offline. - Original Message - From: "Christopher" To: "Accumulo Dev List" Sent: Thursday, December 11, 2014 11:27:48 AM Subject: Re: Planning for (eventual) removal of instance.dfs.{uri,dir} On Thu, Dec 11, 2014 at 10:52 AM, wrote

Re: Google analytics summaries

Sounds good to me. On Dec 11, 2014 11:15 AM, "Sean Busbey" wrote: > I just got the mail summary of our google analytics stats for > accumulo.apache.org. > > Anyone opposed to me starting to forward the summary email to dev@accumulo > ? > It contains summary info like visitor count, countries, bou

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

To be clear -- if you want to address actual problems you've seen WRT compatibility, start up a new thread and we can work through the issues you have seen and what you are fearful of. I'm not seeing the relevance to this discussion and don't want it to get derailed because dealing with the re

Re: Google analytics summaries

No objection here. Either here or notifications@ would be fine. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Dec 11, 2014 at 11:14 AM, Sean Busbey wrote: > I just got the mail summary of our google analytics stats for > accumulo.apache.org. > > Anyone opposed to me starting t

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

On Thu, Dec 11, 2014 at 10:52 AM, wrote: > "Making it required is annoying if users don't have relative paths." > > But this property is used to determine the location of new files. > > No, it's not. Not if you're using instance.volumes. It should only be used for resolving old files in that

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

It has been my experience that testing is always required when upgrading a major component. With the vote to adopt semver, our users will have more of a guarantee that their applications will work through patch and minor version upgrades. It might be useful though to have a document like CHANGES

Google analytics summaries

I just got the mail summary of our google analytics stats for accumulo.apache.org. Anyone opposed to me starting to forward the summary email to dev@accumulo? It contains summary info like visitor count, countries, bounce rate, etc. I figure it's an easy starting point to make more of our communi

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

You're building functions over the location of files in HDFS? Automated configuration of instances? Jeremy Kepner wrote: When we remove functions, do we have any official guidance to our users who may have built applications that use those functions? Right now, the official position is that th

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

Christopher wrote: So, instance.volumes replaces instance.dfs.uri and instance.dfs.dir in 1.6. But, what's our long-term plan for these? I ask, because we still have internal code that uses instance.dfs.uri to resolve relative paths. Should we force these to be re-written at some point (maybe o

Re: Review Request 28873: ACCUMULO-3393 Follow-on work for per-table volume chooser.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28873/#review64737 --- Ship it! LGTM otherwise. server/base/src/main/java/org/apache/acc

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

When we remove functions, do we have any official guidance to our users who may have built applications that use those functions? Right now, the official position is that the Accumulo developers can remove as they see fit. However, this provides no guidance to users as to what they are suppose to

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

"Making it required is annoying if users don't have relative paths." But this property is used to determine the location of new files. - Original Message - From: "Christopher" To: "Accumulo Dev List" Sent: Thursday, December 11, 2014 10:03:56 AM Subject: Re: Planning for (even

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

Well, no, the database will start if we rely on instance.volumes, but we may be unable to find files that have relative paths, if we incorrectly assume /accumulo. Making it required is annoying if users don't have relative paths. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Dec

Re: Planning for (eventual) removal of instance.dfs.{uri,dir}

How so? If someone upgrades from another version and is using a different dir, doesn't specify it in the configuration, and we assume /accumulo, then their database won't start. The other option, which may be safer than making any assumptions, is to make instance.volumes a required parameter wit

Re: accumulo Scanner

One option is to implement a class extending the RowEncodingIterator: http://accumulo.apache.org/1.6/apidocs/org/apache/accumulo/core/iterators/user/RowEncodingIterator.html I personally ha

Re: Review Request 28873: ACCUMULO-3393 Follow-on work for per-table volume chooser.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28873/ --- (Updated Dec. 11, 2014, 8:14 a.m.) Review request for accumulo and Jenna Huston