i have a json field in my table(MySQL Database).
the following is the structure:
{
"article":{
"Key's 1":{
"value":"24"
}
"Key's of the something's 2":{
"value":"55"
}
}
}
i am trying to extract the "value" field of "Key's 1".
Due special character such as single quote and space, i am unable use JSON_EXTRACT function.
It give the error: Invalid JSON path expression.This error is around character position no : 10
My Query:
select
JSON_EXTRACT(analytics_json,'$.article.Key\'s 1.value')As value
from
tbl_json_data;
Even after place a backslash, i am getting the error.
You may escape each JSON path component in double quotes to handle special characters as well as spaces. The following works:
SELECT
JSON_EXTRACT(analytics_json,'$.article."Key''s 1".value') AS value
FROM tbl_json_data;
Demo
Note that your key name actually has two problems. First, it contains a literal single quote. We can handle that by just doubling up two single quotes. The key name also contains whitespace. By escaping in double quotes we may workaround this problem, but it would probably be best to avoid using JSON keys which have whitespace.
Related
In dealing with the headache of the different rulesets with TEXT escaping and JSON escaping, I've come across the issue where double escaping is required to convert a string to a JSON literal. For example, the original UPDATE looks like this:
UPDATE sourcing_item_data SET data_JSON='{"test": "test \ test"}' WHERE ID = 1;
The above simply removes the '\'.
The problem is I can't see how we get a single backslash into the system. Using two \'s causes the Invalid JSON error. Using three \'s does the same. Using four \'s puts in two \'s.
How does one get a single backslash into a JSON literal from a string with MySQL?
Also, has anyone written a SP or Function that scans a string that's supposed to be converted to MySQL JSON to ensure the string is "scrubbed" for issues (such as this one)?
Thanks!
Four backslashes works.
UPDATE sourcing_item_data SET data_JSON='{"test": "test \\\\ test"}' WHERE ID = 1;
You need to double the backslash to escape it in JSON, and then double each of those to escape in the SQL string.
If you print the JSON value it will show up as two backslashes, but that's because it shows the value in JSON format, which means that the backslash has to be escaped. If you extract the value and unquote it, there will just be one backslash.
select data_JSON->>"$.test" as result
from sourcing_item_data
WHERE id = 1;
shows test \ test
DEMO
I am using the following code to export my data frame to csv:
data.write.format('com.databricks.spark.csv').options(delimiter="\t", codec="org.apache.hadoop.io.compress.GzipCodec").save('s3a://myBucket/myPath')
Note that I use delimiter="\t", as I don't want to add additional quotation marks around each field. However, when I checked the output csv file, there are still some fields which are enclosed by quotation marks. e.g.
abcdABCDAAbbcd ....
1234_3456ABCD ...
"-12345678AbCd" ...
It seems that the quotation mark appears when the leading character of a field is "-". Why is this happening and is there a way to avoid this? Thanks!
You don't use all the options provided by the CSV writer. It has quoteMode parameter which takes one of the four values (descriptions from the org.apache.commons.csv documentation:
ALL - quotes all fields
MINIMAL (default) - quotes fields which contain special characters such as a delimiter, quotes character or any of the characters in line separator
NON_NUMERIC - quotes all non-numeric fields
NONE - never quotes fields
If want to avoid quoting the last options looks a good choice, doesn't it?
The table has a field which contains double pipes "||"
I'm not sure how to get the query to recognise the pipes. I guess they are not being interpreted as string literals.
WHERE field LIKE '||%value%||'
The pipe character has no special meaning, neither in a string literal, nor in a like pattern.
Are you really looking for a value that starts and ends with two pipe characters, and contains value somehere between them? For examle ||asdfvalueqerty||.
If you are looking for a value that contains ||value||, you would use the pattern '%||value||%' instead.
I'm using VBA that encloses every field with single quotes in order to import into mySQL and noticed that every variation I tried on NULL for numeric data types imported as 0. If I drop the backticks the nulls import fine, so I think my question boils down to this: if there any way to indicate NULL data inside of single quotes in a mySQL import?
this website shows a bunch of examples, but nothing inside of single quotes.
thanks!
If the string inside the single quotes is escaped, too, then there is no way of making it NULL. That would negate the purpose of quotes+escaping.
If it is not escaped, you could "break out" of the single quotes with a single quote. For example if you store the string '/0+' it will become ''/0+'' (say: empty string divided by zero plus empty string) which is NULL because anything divided by zero is NULL.
From the CSV spec (RFC 4180), Spaces are considered part of a field and should not be ignored. Obviously if the field contains double quotes it should retain the spaces inside the quotes.
My question is, what about spaces outside of the double quotes? The only way I can see this happening is if the tool that generated the CSV didn't do it properly.
Example: one, "two" ,three
Should the space before and after "two" be included?
That cell is invalid - to properly code that row it should be:
one," ""two"" ",three
Double quotes must also be escaped (as double-double quote) since they are used as the escape sequence. If you don't want to preserve the quotes around two, technically there are two things invalid about the row - (1) the spaces before and after the quotes and (2) the fact that there are quotes around the cell but nothing to be escaped. CSV demands that there can only be quotes around the cell if there are commas or quotes inside the content of the cell.
If I were in your case, I would err on the side of leniency.
I dealt with this using BULK INSERT and BCP format files, which is tricky to account for the quote and comma delimiting. In the event that there could be variation, say with a , " delimiter We used the lowest common delimiter, so the comma in your example, then stripped out what wasn't needed like all the double quotes.
But it could also be that your source data was only comma delimited and this was the actual contents of that field. Either way, I would toss out the quotes when loading the field, in whatever method was appropriate.