The issue with giving multiple iterators the same priority is that the API
specifies that during the call to init(), one source is given the iterator.
I fail to see how this is an issue. I don't really want a tree of iterators
(I'm not sure how you'd combine the multiple results moving back
It's because you're building a stack of iterators and the order you set on
the scanner is the order of sources created and passed to init() for each
iterator you create in the stack when the scan is executing on a TServer.
Albeit deprecated, the filtering API in 1.3 does allow you to set multiple
+1 for a configuration file property -- perhaps this could be worked
into the Encoding class David describes below.
On Tue, Oct 30, 2012 at 10:35 PM, John Vines vi...@apache.org wrote:
Why not just have a configuration in the xml file for setting a global
charset? This way we avoid hard coded
Related to the discussion of the getBytes() issue, I had a question about
commit policy in the Accumulo project.
Has there been any discussion regarding commit policy in general in the
Accumulo project? Are there certain times where committing an approach when
it is under discussion is acceptable
I think the core policy should be if you think your change is at all likely
to be rolled back then don't commit it. This applies to tickets with active
debates. I also don't think we need to be heavy handed in policy -- shame
of roll back is enough motivation and the cost isn't that high. This
On Wed, Oct 31, 2012 at 12:18 PM, Adam Fuchs afu...@apache.org wrote:
I think the core policy should be if you think your change is at all likely
to be rolled back then don't commit it. This applies to tickets with active
debates. I also don't think we need to be heavy handed in policy -- shame
Should this conversation move to
https://issues.apache.org/jira/browse/ACCUMULO-840?
On Wed, Oct 31, 2012 at 11:51 AM, Drew Farris d...@apache.org wrote:
+1 for a configuration file property -- perhaps this could be worked
into the Encoding class David describes below.
On Tue, Oct 30, 2012 at
Not wanting to merge is a terrible reason to commit a patch. A patch file
would have been more then sufficient until we reached a consensus on
implementation. The worst case is that the patch had to be merged properly,
which someone would have had to do. We are a community, and if one person
does
On Wed, Oct 31, 2012 at 12:09 PM, Drew Farris d...@apache.org wrote:
Related to the discussion of the getBytes() issue, I had a question about
commit policy in the Accumulo project.
Has there been any discussion regarding commit policy in general in the
Accumulo project? Are there certain
+1
See reviews.apache.org.
Cheers,
Adam
On Wed, Oct 31, 2012 at 1:38 PM, Keith Turner ke...@deenlo.com wrote:
On Wed, Oct 31, 2012 at 1:01 PM, John Vines vi...@apache.org wrote:
Not wanting to merge is a terrible reason to commit a patch. A patch file
would have been more then sufficient
On Wed, Oct 31, 2012 at 1:38 PM, Keith Turner ke...@deenlo.com wrote:
On Wed, Oct 31, 2012 at 1:01 PM, John Vines vi...@apache.org wrote:
Not wanting to merge is a terrible reason to commit a patch. A patch file
would have been more then sufficient until we reached a consensus on
A slight
I've added my own comments to this thread on the ACCUMULO-840 ticket.
https://issues.apache.org/jira/browse/ACCUMULO-840?focusedCommentId=13488024page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13488024
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue,
On Wed, Oct 31, 2012 at 1:49 PM, Benson Margulies bimargul...@gmail.com wrote:
On Wed, Oct 31, 2012 at 1:38 PM, Keith Turner ke...@deenlo.com wrote:
On Wed, Oct 31, 2012 at 1:01 PM, John Vines vi...@apache.org wrote:
Not wanting to merge is a terrible reason to commit a patch. A patch file
13 matches
Mail list logo
