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.
Related
I've read through a few questions on this and I'm still unclear. Which is correct:
{"some_parameter": "true"}
or
{"some_parameter": true}
I assume the second is the correct, proper way to send boolean values via json? But the first is still valid json...
The context here is that I'm building an API (used by some 3rd party applications) and I'm wondering if it's reasonable to simply disallow the first type altogether (reject with error) or accept boolean data as strings like this, and just attempt to handle (convert) them?
Short answer, yes that is the proper way to send the JSON. You should not be placing anything other than a string inside of quotes.
Long answer,
It depends on the data type. For the Key, yes you have to use quotes but only for strings. Also, you can use single quotes if you want to place a quotation mark inside of it. (or use escape)
'
for instance,
vs
"
As for your bool value, if you want it to convert straight into a bool, than you do not need to include the quotes. Same for integers and double values.
But if you want to pass it as a string, than you will need to put it inside of quotes.
Generally, these types of questions are asked when you discuss what types of systems will be accepting your data.
It's generally much easier to use strings everywhere, but it's also extremely inefficient and results in your recipient needing to cast them if they want to do arithmetic with an int for instance, but it's passed as a string.
Boolean values must be passed without quotes. Boolean is one of the types supported by json: https://www.json.org/json-en.html and the expected values are true or false, without quotes.
It may still work with quotes when the receiving end parsing the data is a weak typing language like Javascript which converts the value automatically when you use it in a boolean context, but it's always better to follow what the standards say.
Yes, We can pass Boolean value in Json. Just we need to write value in small case.
For Example
{
"fullName": "Deepak Dongre",
"gender": true,
"dob": "1986-11-16",
"mobileNumber": 97959000321,
"tblMstHobbyDetails": []
}
I am very bad at creating Regular Expression. therefore, thought of asking for help here. I tried googling but was not able to get much out from there.
I have a Json object that I have converted to a string. The result is as below:
{
"ContainerId": "<script>alert('hi')</script>>>",
"AssociateId": "abc22<script>",
"Header": {
"ApiVersion": null,
"JsonWebToken": null,
"MessageId": "<script>1de11a8e-</script>b6df-4835-aba0-5d9ea59acf59"
},
"StoreNumber": "9913"
}
I actually wanted to encode the values of the Json object. So I thought of using regex to match below value from the json and when value found, replace all next value till the closed double inverted commas.
Value to match :
: "
Example
"ContainerId": "<script>alert('hi')</script>>>",
I only wanted to encode value here that occur right after : "
I was successful encoding the value via using Jproperty, but now wanted to do that via Regex.
Here is the regex that matches your requirement
:[\s]\"(.*?)"
You will find your data in the first match group, You can try it Here
Now to replace those occurrences, it would depend on the programming language you use.
I'm using SugarCRM rest API, and according to the documentation, to get a set of records, I have to use /<module> GET endpoint and pass JSON in the body to filter the query.
First, is it even possible to have a body in a GET request ?
and how can I build this kind of request then ?
I'm using postman and tried to pass parameters as query strings but it's not possible though.
As far as I know you have to put everything in the query string, which might look different to what you'd expect.
Example for a request to /Users:
{
max_num: 100,
fields: ["first_name", "last_name"],
filter: [
{"user_name":"admin"}
{"status":"Active"}
]
}
Written as query string this request will look like this:
/rest/v10/Users?max_num=100&fields=first_name,last_name&filter[0][user_name]=admin&filter[1][status]=Active
Observations regarding the query string format:
There is no { or }, the values of the request object are placed directly in the query string
Key-Value pairs are assigned with =, and separated by & (instead of : and ,)
There are no " or ' quotes at all, strings are written without those
An array of values (here: fields) is just one assignment with all values separated by ,
An array of objects (here: filter) has one Key-Value pair per bottom value and uses [ and ] to indicate the "path" to each value. Using 0-based numerical indices for arrays
Notes
Keep in mind there are length limits to URL incl. query string. E.g. 4096 bytes/chars for Apache 2, if I remember correctly. If you have to send very elaborate requests, you might want to use POST /rest/v10/<module>/filter instead.
URL-escaped (usually not necessary) the example filter would look like this:
/rest/v10/Users?max_num%3D100%26fields%3Dfirst_name%2Clast_name%26filter%5B0%5D%5Buser_name%5D%3Dadmin%26filter%5B1%5D%5Bstatus%5D%3DActive
I'm struggling with this, which I feel should work but maybe I'm doing something stupid. This search:
{
"query":
{
"bool":
{
"must":[
{"match":{"Element.sourceSystem.name":"Source1 Source2"}}
]
}
}
returns data for both Source1 and Source2. Adding a terms search, as underneath, I would expect to return a subset of the first search with just the Source1s returned. Nothing is returned, when run with the first query or on it's own.
{
"query":
{
"bool":
{
"must":[
{"match":{"Element.sourceSystem.name":"Source1 Source2"}},
{"terms":{"Element.sourceSystem.name":["Source1"]}}
]
}
}
}
I realise this is hard without seeing the documents, but suffice it to say that "Element.sourceSystem.name" exists and is available as the first search works fine - all input gratefully received.
There are some things that are handled differently in match queries than in terms queries.
First of all, a detour to analyzers:
Assuming you are using the standard analyzer of elasticsearch, which consists of a standard tokenizer and some token filters. The standard tokenizer will tokenize (split your text into terms) on spaces, punctuation marks and some other special characters. Details can be found in the Elasticsearch Documentation, so for now let's just say 'each word will be a term'.
The second, very important part of the analyzer is the lowercase filter. It will transform terms into lowercase. This means, later on, searching for Source1 and source1 should yield the same results.
So a short example:
Input : "This is my input text in English." will be analyzed and end up with the following terms: "this", "is", "my", "input", "text", "in", "english".
All of this happens when you index a document into a text field for example. I assume the Element.sourceSystem.name is one of this type, since your normal match query seems to work.
Now, when you issue a match query with "Source1 Source2", the analysis will also happen and transform it into tokens source1 and source2. Internally it will then create 2 term queries in a boolean OR. So either source1 or source2 must match to be a result of your query.
By the way, the match query supports a minimum_should_match property. You could specify, how many terms of your match query need to match.
Here's now the clue with the terms query. It does not analyze the text you provide. It's usually supposed to be used on fields of type keyword. Keyword fields are also not analyzed (for further information, please read the documentation of mapping types - it is actually pretty important). So what does this mean?
If I take my example from above, my index would contain "this", "is", "my", "input", "text", "in", "english".
A match query with English will match, because it will be analyzed to english
A term/s query with English will never match, because there is no term English in my index. It is case sensitive.
I am very positive, if you would use source1 in your terms query, it would match something. However, I highly doubt that your query is the way to go for your use case. Try using normal match queries when querying text fields and (in general - not always applicable) only use terms queries on keyword fields.
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.