You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "hlgp (via GitHub)" <gi...@apache.org> on 2023/05/01 18:51:44 UTC
[GitHub] [accumulo] hlgp opened a new issue, #3367: Accumulo 2 shell scans require escape characters where Accumulo 1 did not
hlgp opened a new issue, #3367:
URL: https://github.com/apache/accumulo/issues/3367
**Describe the bug**
If any part of the key has something like a null character separator, we used to be able to scan without escaping in Accumulo 1, but now we have to in Accumulo 2.
e.g. for a composite edge key:
apple\x00banana
In Accumulo 1 we used to be able to run: 'scan -r apple\x00banana'
but now in Accumulo 2 we have to add a slash: 'scan -r apple\\x00banana'
We have a variety of scripts we'd need to update to handle this. It is also not backwards compatible i.e. if we try to scan Accumulo 1.* with the extra slash, we get nothing. We were wondering if it was intentional.
**To Reproduce**
Create a row with a null separator in the rowid and scan.
**Expected behavior**
We would expect to be able to scan the same way between Accumulo 1 and 2.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] hlgp commented on issue #3367: Accumulo 2 shell scans require escape characters where Accumulo 1 did not
Posted by "hlgp (via GitHub)" <gi...@apache.org>.
hlgp commented on issue #3367:
URL: https://github.com/apache/accumulo/issues/3367#issuecomment-1530274094
I haven't tested them all yet, but so far they fail silently since the main symptom is retrieving no data due to the missing escape character. If I find a case where an error is thrown, I'll post again.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3367: Accumulo 2 shell scans require escape characters where Accumulo 1 did not
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3367:
URL: https://github.com/apache/accumulo/issues/3367#issuecomment-1530209460
I'm not sure what the full extent of the escaping feature is in JLine, but it would be great if we could get rid of our custom parsing of lines, and let JLine be responsible for all the escaping.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] dlmarion commented on issue #3367: Accumulo 2 shell scans require escape characters where Accumulo 1 did not
Posted by "dlmarion (via GitHub)" <gi...@apache.org>.
dlmarion commented on issue #3367:
URL: https://github.com/apache/accumulo/issues/3367#issuecomment-1530257638
> We were wondering if it was intentional.
This was not intentional, but is a side-effect of a dependency upgrade. It looks like JLine was version 2.11 in Accumulo 1.10.x and 2.0.0. It was upgraded to 3.x in Accumulo version 2.1.0.
> Expected behavior
We would expect to be able to scan the same way between Accumulo 1 and 2.
I'm not sure about this given that this is a major version increase. APIs and behaviors change. However, I wonder if this change in a minor version (2.0 to 2.1) should be expected by users. I'm glad that you found this during testing. Do the scripts fail silently, or do you get an error?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3367: Accumulo 2 shell scans require escape characters where Accumulo 1 did not
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3367:
URL: https://github.com/apache/accumulo/issues/3367#issuecomment-1530215429
I would strongly recommend, though, that if this is breaking anybody, they should seriously consider using JShell to do their custom scripts. The Accumulo shell is a very minimal solution for very basic functionality. Any serious work should be done in Java directly. JShell allows you to do this quite easily, for small Java applications. And we have a convenient entry point for JShell (`bin/accumulo jshell`) that sets up an execution environment with the Accumulo classpath and create an initial AccumuloClient ready-to-use.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] dlmarion commented on issue #3367: Accumulo 2 shell scans require escape characters where Accumulo 1 did not
Posted by "dlmarion (via GitHub)" <gi...@apache.org>.
dlmarion commented on issue #3367:
URL: https://github.com/apache/accumulo/issues/3367#issuecomment-1530182946
This is likely due to the upgrade of JLine to version 3. The escape character in their default line parser is set [here](https://github.com/jline/jline3/blob/master/reader/src/main/java/org/jline/reader/impl/DefaultParser.java#L53). I'm wondering if the solution is:
```
DefaultParser parser = new DefaultParser();
parser.setEscapeChars(new char[] {(char) 92});
reader = LineReaderBuilder.builder().terminal(terminal).parser(parser).build();
```
We'll have to test that out.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org