when doing large json imports with arangoimp (using ArangoDB 2.4.0), sporadically a warning comes up:
2015-01-15T11:30:30Z [1268] WARNING at position 22213: invalid JSON type (expecting array)
The encording lines (here 22213) contents a proper json object. Is there a way to let arangoimp print for which attribute it expects an array?
As we are using schemeless documents, why is arangoimp insisting in getting an array anyway?
If this is a WARNING why is it reported as error at the end?
created: 25416
errors: 297
total: 25713
The warned documents indeed where not imported.
I have just pushed a change that will improve diagnostics for these cases:
https://github.com/triAGENS/ArangoDB/commit/d7fa7e7a928d3d998fc8dddb372d07417c3d6646
It will produce better error messages, print the offending document and may also print the offending line in case of parse errors.
It also addresses the issue that warnings and errors are effectively the same when importing. So it now prints "warnings/errors" instead of just "errors".
Related
In my Cosmos DB the nested property names include a .(dot). I've tried every combination I can think of including special character handling, but I keep getting the error "incorrect syntax". How can I handle the .(dot) to get the values in eRecord.01?
You can use the following syntax to solve your problem:
c.data.eRecord["eRecord.01"]
Some error messages (those encountered by the beginners mostly) are not friendly enough for beginners themselves:
Error: 'str ' object does not support item assignment
I think a more suggestive, less cryptic message would be:
Error: value reassignment inside the 'str' object not supported
Also, to create in Python a list of all tags stackoverflow supports might come handy as for me it will take a lifetime to get 1500 reputation and create a new tag. Thanks in advance.
I have ran into an issue on Windows where encoded file is read and decoded using EncodingGroovyMethods#decodeBase64:
getClass().getResourceAsStream('/endoded_file').text.decodeBase64()
This gives me:
bad character in base64 value
File itself has CRLF endings and groovy decodeBase64 implementation snippet has a comment so:
} else if (sixBit == 66) {
// RFC 2045 says that I'm allowed to take the presence of
// these characters as evidence of data corruption
// So I will
throw new RuntimeException("bad character in base64 value"); // TODO: change this exception type
}
I looked up RFC 2045 and CLRF pair is suppose to be legal. I have tried same with org.apache.commons.codec.binary.Base64#decodeBase64 and it works. Is this a bug in groovy or was this intentional ?
I am using groovy 2.4.7.
This is not a bug, but a different way of how corrupt data is handled. Looking at the source code of Base64 in Apache commons, you can see the documentation:
* Ignores all non-base64 characters. This is how chunked (e.g. 76 character) data is handled, since CR and LF are
* silently ignored, but has implications for other bytes, too. This method subscribes to the garbage-in,
* garbage-out philosophy: it will not check the provided data for validity.
So, while the Apache Base64 decoder silently ignores the corrupt data, the Groovy one will complain about it. The RFC documentation is a bit fuzzy about it:
In base64 data, characters other than those in Table 1, line breaks, and other
white space probably indicate a transmission error, about which a
warning message or even a message rejection might be appropriate
under some circumstances.
While warning messages are hardly useful (who checks for warnings anyway?), the Groovy authors decided to go into the path of 'message rejection'.
TLDR; they are both fine, just a different way of handling corrupt data. If you can, try to fix or reject the incorrect data.
I'm using HUnit-Plus via stack test, which I believe makes use of Distribution.TestSuite.
When I get compilation errors, I get file paths and line numbers in the error. This is great because I can just click on the error in my editor and jump straight to the relevant code.
Other times there is no compilation error and instead I get output like this:
### Failure in testFoo: expected: 8
This isn't so great, because every time I have to navigate to the relevant test by hand. Also, it is sometimes ambiguous which assertion has failed, and I have to add a string to label the assertion, which becomes repetitious because the string merely repeats in some form the content of the assertion (or else is meaningless). With a line number that wouldn't be a problem.
Is there a way to get this setup to print line numbers and file paths for test failures?
Compilation errors are generated by GHC itself which gives you line numbers, to my knowledge no test suite has this feature, which would be a really nice thing to have though. What I found quite helpful is hspec-expectations-pretty-diff which is a nice diffing output but with no line numbers, I checked it also provides file path and line number!
Also I see some space for improvement for your test cases - usually a test case in my project has a string describing the test - therefore it is rarely ambiguous what test case failed. Also you can use the whole power of haskell to generate this String!
export is not working for csv:
(org.displaytag.decorator.MessageFormatColumnDecorator:66 - decorate) ==> Caught an illegal argument exception while trying to format an object with pattern {0,date,dd-MMM-yyyy}, returning the unformatted value. Object class is {0,date,dd-MMM-yyyy}
exception is :(org.displaytag.decorator.MessageFormatColumnDecorator:66 - decorate) ==> Caught an illegal argument exception while trying to format an object with pattern {0,date,dd-MMM-yyyy}, returning the unformatted value. Object class is {0,date,dd-MMM-yyyy}
Make sure you don't have escapeXml="true" as a property for your display:column tag.
I know it's probably too late for the OP to get this answer, but I think this could help some people stuck with this problem.