I am trying to store decimal numbers with restricted number of decimal places in my JSON data, and initially, I wanted to do it using strings. However, the schema does not support this. So as of right now, I am restricted to using this:
{"type": "number", "multipleOf" : 0.1} <- 1 decimal place
{"type": "number", "multipleOf" : 0.01} <- 2 decimal places
This works fine in dev, but I know from first hand experience how quickly floats can break down in actual applications. So my first choice is still finding some way to store them as strings in my data. Is this possible with the current implementation of JSON Schema?
This is not something that is possible with JSON Schema for numbers.
If you can represent your number as a string, you can use regex in the JSON Schema to check this sort of thing.
Look up the pattern key word.
As per the previous answer, If you are happy to represent the number as a string, you can use a regex pattern.
The below will restrict a number to 15sf (potentially useful if you are concerned about floating point expressibility):
{
"type": "string",
"pattern": "^(?!(?:.*?[1-9]){15,})([-+]?\\s*\\d+\\.?\\d*?)$"
}
Related
I'm new to solr. Can someone explain what the delimited_payload_string field type is?
For example, can I store the following JSON object as a multi-valued delimited_payload_string?
"classifications": [
{"code": "RESTAURANT", "names": [{"nameLocale": "en-US", "name": "restaurant"}, {"nameLocale": "en-US", "name": "fast food"}]}
]
A delimited payload string is for attaching a payload to a specific field - a payload is an additional value that isn't visible in the document, but can be used by custom plugins. From Solr Payloads
Available alongside the positionally related information is an optional general purpose byte array. At the lowest-level, Lucene allows any term in any position to store whatever bytes it’d like in its payload area. This byte array can be retrieved as the term’s position is accessed.
[...]
A payload’s primary use case is to affect relevancy scoring; there are also other very interesting ways to use payloads, discussed here later. Built-in at Lucene’s core scoring mechanism is float Similarity#computePayloadFactor() which until now has not been used by any production code in Lucene or Solr; though to be sure, it has been exercised extensively within Lucene’s test suite since inception. It’s hardy, just under-utilized outside custom expert-level coding to ensure index-time payloads are encoded the same way they are decoded at query time, and to hook this mechanism into scoring.
In your case you probably want to flatten the document before indexing and indexing the value as separate tags, depending on what you want to do with the data.
The below JSON file costs 163 bytes to store.
{
"locations": [
{
"station": 6,
"category": 1034,
"type": 5
},
{
"station": 3,
"category": 1171,
"type": 7
},
]
}
But, If the values are put together as a string with delimiters ',' and '_', 6_1034_5,3_1171_7 costs only 17 bytes.
What are the problems with this approach?
Thank you.
The problems that I have seen with this sort of approach are mainly centered around maintainability.
With the delimited approach, the properties of your location items are identified by ordinal. Since there are all numbers, there is nothing to tell you whether the first segment is the station, category, or type; you must know that in advance. Someone new to your code base may not know that and therefore introduce bugs.
Right now all of your data are integers, which are relatively easy to encode and decode and do not risk conflicting with your delimiters. However, if you need to add user-supplied text at some point, you run the risk of that text containing your delimiters. In that case, you will have to invent an escaping/encoding mechanism to ensure that you can reliably detect your delimiters. This may seem simple, but it is more difficult than you may suspect. I've seen it done incorrectly many times.
Using a well-known structured text format like XML or JSON has the advantages that it has fully developed and tested rules for dealing with all types of text, and there are fully developed and tested libraries for reading and writing it.
Depending on your circumstances, this concern over the amount of storage could be a micro-optimization. You might want to try some capacity calculations (e.g., how much actual storage is required for X items) and compare that to the expected number of items vs. the expected amount of storage that will be available.
This question already has answers here:
How to use if statement inside JSON?
(6 answers)
Closed 5 years ago.
I want to include an if-else condition in JSON based on which I need to set an attribute in the JSON file.
For example like this:
"identifier": "navTag",
"items": [{
"label": "abc",
"url": "yxz.com",
},
{
"label": "abc1",
"url": "yxz1.com",
},
{
"label": "abc2",
"url": "yxz2.com",/*I need to change this value on certain
condition like if condition is true then
"url": xyz2.com if false "url":xyz3.com*/
}
]
Is this possible?
JSON is a structure for storing data so that we can retrieved it much faster comparative to other data structure.So we can not give some conditions here.If you want to retrieve some data according to some if-else condition then there is two possible way,
1.We can create different JSON files for different conditions.
2.We can create two field in your JSON structure called if and else.If if condition satisfied then fetch the if field's value and if else satisfied then retrieved the else field's value.
eg:
{
"if":"if-value",
"else":"else-value"
}
JSON is only a data representation (unrelated to any programming language, even if early JavaScript implementations remotely inspired it). There is no notion of "execution" or "conditional" (or of "behavior" or of "semantics") in it.
Read carefully the (short) JSON definition. It simply defines what sequence of characters (e.g. the content of a file) is valid JSON. It does not define the "meaning" of JSON data.
JSON data is parsed by some program, and emitted by some program (often different ones, but could be the same).
The program handling JSON can of course use conditions and give some "meaning" (whatever is the definition of that word) to it. But JSON is only "data syntax".
You could (easily) write your own JSON transformer (using some existing JSON library, and there are many of them), and that is really simple. Some programs (notably jq) claim to be more or less generic JSON processors.
Since JSON is a textual format, you could even use some editor (such as emacs, vim or many others) to manually change parts of it. You'll better validate the result with some existing JSON parser (to be sure you did not add any mistakes).
Currently I'm working on a REST API with an object that has a status. Should I return the status as a string or as an object?
When is it smart to change from field being a primitive type to a field being an object?
[
{
"id": 1
"name": "Hello"
"status": "active"
},
{
"id": 1
"name": "Hello"
"status": {
"id": 0
"name": "active"
}
}
]
In terms of extensibility I would suggest going for and object.
Using an object also adds the advantage of being able to split responsibility in terms of identifying (via f.e. an id field) and describing (via f.e. a name or description field), in your case, a status.
Adding i18n as a possible necessity, an object would also have to carry a string as identifier.
All these things are not possible with simple primitives. Conclusion: go for an object.
Other interesting remarks are given here.
It depends on what you need to pass.
If you only want to distinguish between different states and have all other related information (strings, translations, images) on the client either way, you might only want to send a simple integer value and use an enum on the client side. This reduces the data to the smallest amount.
If you have data that changes within one status on the server side, you need an object to pass everything else.
But best practice here would be to reduce data as much as possible.
I do not understand why but for some cases filter does not work.
Below is my example:
/v2/entities?type=carparks&q=name==Parking+Tina+Balice+Krakow&options=keyValues
returns:
[
{
"id": "15217701",
"type": "carparks",
"agglomerations": "1",
"name": "Parking Tina Balice Krakow"
}
]
The above axample works correctly but second query does not work:
/v2/entities?type=carparks&q=agglomerations==1
This query returns empty string.
How to filter out this condition:
type = carparks and agglomerations==1
for this object?
Orion:
version": "1.2.0"
Whitespaces in URL query needs to be correctly encoded, either with + or %20. Have a look to this document.
Thus, try the this way
/v2/entities?type=carparks&q=name==Parking+Tina+Balice+Krakow&options=keyValues
or this other
/v2/entities?type=carparks&q=name==Parking%20Tina%20Balice%20Krakow&options=keyValues
EDIT: regarding
/v2/entities?type=carparks&q=agglomerations==1
Note that agglomerations is an string, while by default equal filter search for numbers (when the value to search is a number, of course). Thus, you have two alternatives:
Force to interpret the value as string, using single quotes:
/v2/entities?type=carparks&q=agglomerations=='1'
Create/update the entity using numeric values for agglomerations. This is the option that probably makes more sense as I understand that the agglomerations semantic is of numeric nature.