I am looking for an elegant way of checking that a value is a valid regular expression in a JSON schema. So far I have been content with requiring a string type:
{
"pattern": { "type": "string" }
}
I would like to make my check more strict and see that pattern is a valid regular expression:
{
"definitions": {
"regex": {
??? #not another regex -- that was already disproved
}
}
"pattern": { "type": "regex" }
}
By valid I mean checking that there are no syntax errors in the regular expression, such as open parentheses and so on.
I thought for a while that one of the possible solutions was a regex that would match a regex, but I was shown this was already discussed for instance in Regexp that matches valid regexps, turning out that such an approach was impossible. What other ways are there? I can think of a few directions this could lead, but could not find any information. Can I have the schema validator, for instance, somehow compile the regex? Do some validators support a regex primitive type unofficially? Is it in line to become a primitive type in JSON Schema v5, or some standard extension? Can I ``shell out'' of the schema and make the check? Or anything else?
Then I'd have to agree with what's said in Regexp that matches valid regexps - It's not possible.
However, I guess you could limit the complexity of the allowed regex, e.g. in it's most limited way maybe \.\* only allowing the regex .*, up to more complex, but still simple, constructs. Like
^(?:(?:[.\w\s]|\\w|\\d|\\s)(?:\*|\+|{\d+(?:,\d*)?})?)+$
allowing things like .* as well as prefix\d+postfix, \w{1,3}\d+, and so on...
(This was meant as a comment, but could be a possible answer, so... ;)
Regards
Related
I need to be able to access all the available JSON data, the problem is that a lot of it is nested.
I currently have this query.
SELECT * FROM `system_log` WHERE entry->"$[0]" LIKE "%search_term%";
I need instead of entry->"$[0]", something like entry->"$*"
I think the arrow syntax is short for JSON_EXTRACT which I think would mean that a solution for extract would work for the arrow syntax.
{
" Name": {
"after": "Shop",
"before": "Supermarket"
}
}
This is an example of my JSON data and as you can see there are multiple levels to it meaning that entry->"$[0]" won't catch it.
version 8.0.19 of SQL
What I've tried so far is entry->"$[0]" and then prepending [0] after, but this solution does not seem very dynamic as the JSON data could get deeper and deeper.
JSON_SEARCH() won't work for the search you describe, because JSON_SEARCH() only searches for full string matches, not wildcards.
If you truly cannot predict the structure of your JSON, and you just want to find if the pattern '%search_term%' appears anywhere, then just treat the whole JSON document as a string, and use LIKE:
SELECT * FROM `system_log` WHERE entry LIKE "%search_term%";
If you have more specific search requirements, then you'll have to come up with a way to predict the path to the value you're searching for in your JSON document. That's something I cannot help you with, because I don't know your usage of JSON.
Here is my JSON code.
{
"user_email": "{User.Email}",
"activity_date": "{Lead.LastAction.Date}",
"record_id": "{Lead.Id}-{Lead.LastAction.Date}",
"action_type": "{Lead.LastAction}",
"milestone": "{Lead.Milestone}",
"date_added": "{Lead.Date}"
}
Is it possible to add calculations in the code?
For example, can I add a line where the date_added is subtracted from activity_date?
No: JSON is a way to transport JS Objects.
You can do that while you format the JSON in your native language ( for example in PHP or JS serverside), basically creating the JSON object with the result of the calculation.
In JSON just by itself you cannot do that, it's just a data format, it's totally passive, like a text file. (If you happen to use JSONP, then the story would be a bit different, it might be possible, but using JSONP to do such things would step into area of 'hack/exploit' and it probably should not be used in that way:) )
However, I see you are using not only JSON - there is some extra markup like {User.Email}. This is totally outside JSON spec so clearly you are using some form text-templating engine. These can be quite intelligent at times. Check that path, see which one you are using, see what are its features, maybe you can write a custom function or expression to do that subtraction for you. Maybe, just maybe, it's as easy as
"inactivity_period": "{Lead.LastAction.Date - Lead.Date}"
or
"inactivity_period": "{myFunctionThatIWrote(Lead.LastAction.Date, Lead.Date)}"
but that all depends on the templating engine.
I have a number of requests types I might be sent.
There's a request-type property that may have values "add", "update", "delete" (for example).
Depending on the request type, I will get different properties
If the request type is "add", then I will get additional propertie "add-red", "add-blue", "foo" for example
If the request type is "update,, then "update-xxx", "update-yyy", "update-xxx"
and if "delete" then "foo", "bar"...
Note that some additional properties could appear for more than one request type (see "foo" in the above example)
So I want to validate differently depending on the value of "request-type".
I tried to to
"oneOf": [
{
...
"properties": { "request-type" : { "enum": ["add"] }
"add-red": { ...}
}
},
{
...
"properties": { "request-type" : { "enum": ["update"] }
"update-xxx": { ...}
}
}
In the hope that the validator would match the value of the first when deciding which of the "oneOf" would be selected.
This appears itself to be "valid" (in that the VS Code validator thinks it's a valid schema) but doesn't do what I want - it seems when I write the corresponding JSON it always matches the first, and will only accept "add" as its value).
So how should I do this? I can define the JSON format here, so I can require the use of something I can validate somehow.
It's nearly a duplicate of this: JSON schema anyOf validation based on one of properties except I think the answer there requires distinct sets of additional properties for each request type.
EDIT: According to the answer to validation of json schema having oneOf keyword
it looks like my approach should work so maybe this is just a limitation of the intellisense in MS VS Code?
EDIT2: And this gives another approach: writing more complex json schemas that have dependencies upon other keys
I'll have to experiment some more and maybe end up deleting this!
Answering my own question - the approach of the question works fine. Using a validator like http://www.jsonschemavalidator.net/, I get the behaviour I expect.
It's just that Visual Studio Code's intellisense can't interpret it in a way that means it can provide useful guidance (and to be fair, it's a difficult problem as it means partially matching all the of the alternatives in the "oneOf" to see which ones might still be valid)
I want to know if the next value is valid as a JSON format
1223452234
I am using AFNetworking in my iOS app and allow the parse of it with
readingOptions: .AllowFragments
And it works... but it is a valid JSON? what's the name of that kind of things?
Thanks
To my knowledge you must be in an array or object type for the root element.
This means you could have something like this if you really wanted it to be as "small and simple" as possible.
[
12341234
]
or this if you need keys.
{
"test": 321321312
}
I don't think the numbers by themselves are valid and they're definitely not standard.
I am asking this because I see that the current JSON schema draft (http://json-schema.org/) proposes to have the schema of JSON in the following way:
for the JSON :
{
"a":"abc"
"b": 123
}
the schema proposed in the draft is like
{
"type":"object"
"properties":{
"a": {"type":"string"}
"b": {"type":"integer"}
}
}
My question here is does the JSON itself not define its structure? Is a separate schema necessary?
The schema proposed by the draft validates the JSON that have the above structure and those JSON are always of the format
{
"a":"string"
"b": 1 (or some number)
}
So what is the need of a separate schema for JSON. We can simply use the JSON to define its structure also.
PS. I know that we can specify some restrictions on the values that the JSON can take through the schemas proposed in the draft, but from the point of view of defining structure of a JSON, are the proposed schemas necessary?
The JSON itself does not define the structure. For example, I could write:
{
"a": "string",
"b": "another string"
}
That's also valid JSON - but it's "differently structured" JSON, because "b" is now a string. But your API might only accept JSON with a particular structure, so although it's valid JSON, it's not the shape you need.
Now, do you need JSON Schema to define the structure of your JSON data? No. You could instead say:
The value must be an object. It must have two properties:
"a" - must be a string
"b" - must be an integer
A programmer could understand this very easily, with no squiggly brackets or anything.
However, there are advantages to having a machine-readable description of the format, because it lets you automate various things (e.g. testing, generating documentation, generating code/classes, etc.)
Edit: As pointed out in the comments, you can take the type information from some example data, and use that as a model for other data. In this case, you're basically using your example data as a super-basic schema.
For very simple constraints (basic type), this works. However, how would you say that "b" has to be an integer instead of a float? How do you say that "b" must be > 0? How do you say that "a" must not be the empty string ("")?
There are indeed tools that generate a basic JSON Schema from example data - however, the resulting schema usually requires a bit of tweaking to actually describe the format (e.g. min/max, required/optional properties, etc.).
Until now have never been necessary and in the short term I don't think it gets to be.
I personally like JSON because its simplicity, portability and flexibility.
I don't see even major brands using that schema so until now they don't take its serious.