Filter 'or' and 'and' together in Loopback 4 - rest

I am using loopback 4 and trying to use filter [and] and [or] together via rest api. I have a table like this
what i want is to show only items which has cond1 = 0 and cond2 = 0 and (cond3 = 1 or cond3 = 2 or cond3 = 3).
the json would be like this
{
"and": [
{
"cond1": 0
},
{
"cond2": 0
},
{
"or": [
{
"cond3":1
},
{
"cond3":2
},
{
"cond3":3
}
]
}
]
}
this is my rest api filter
filter[where][and][0][cond1]=0&filter[where][and][1][cond2]=0&filter[where][and][2][or][0][cond3]=1&&filter[where][and][2][or][1][cond3]=2&&filter[where][and][2][or][2][cond3]=3
i've found similar post here and what i've done looks similar with Ebrahim Pasbani answers.
But instead of getting this result
I'm getting this one
which means the [and][2][or][0] syntax is miss understood by loopback as [neq]. I've tried to ask around but looks like anyone else had same problem with me and end up unsolved. i'd appreciate any answer and it possible with some explanation.
thanks before

found the answer on loopback telegram groups.
aparently you can write json string at rest api (with symbol translation for sure). so the answer is :
filter={%22%where%22:{%22and%22:[{%22or%22:[{%22cond3%22:1}{%22cond3%22:2},{%22cond3%22:3}]}],%22cond1%22:0,%22cond2%22:0}}
note: %22 => " in url string.
and voilaa....
the result is exactly as i expected. Hope this could answer for anyone who hit the same issue.

Related

JSONB filter on select via Supabase

I have such a logic (attributes column's type is JSONB - array of objects) that works:
But I want to implement logical OR here if trait_type is equal ... not AND:
JSONB's column structure:
[
{
"value":"Standard Issue Armor 1 (Purple)",
"trait_type":"Clothes"
},
{
"value":"Standard Issue Helmet 1 (Red)",
"trait_type":"Full Helmet"
},
{
"value":"Chrome",
"trait_type":"SmartSkin"
},
{
"value":"Base Drone (Blue)",
"trait_type":"Drone"
},
{
"value":"Thick",
"trait_type":"Eyebrows"
}
]
How that could be done?
Thanks in advance!
I didn't verify the code, so might not work, but I believe at least is in the right direction. You can use the .or() filter to connect multiple filters with logical or operator. For contains(), you can use the cs keyword inside the or filter like this:
const { data, error } = await supabase.from('NTFs')
.select('name, id_in_collection, owner_address')
.eq('collection_id', Number(id))
.contains('attributes', JSON.stringify([{trait_type: 'SmartSkin', value: 'Chrome'}]))
.or(`attributes.cs.${JSON.stringify([{trait_type: 'Drone', value: 'Armed Drone (Blue)'}])}`, `attributes.cs.${JSON.stringify([{trait_type: 'Drone', value: 'Armed Drone (Green)'}])}`)
.order('id_in_collection')
.range(fromIndex, toIndex)

Wiremock Request Templating for JSON Payload with multiple allowed keys, but same response

Trying to mock an API endpoint that allows a request with 2 possible payloads, but the same response:
Request Option 1
{
"key1": "value1"
}
Request Option 2
{
"key2": "value2"
}
Based on the Request Templating documentation, I see that there's an option to define some regex for matchesJsonPath.
However, I'm unable to figure out how to provide a configuration that will allow key1 or key2.
This is what I'd tried, but it doesn't seem to work:
{
// ... other configs
"request": {
"bodyPatterns": [
{
"matchesJsonPath": "$.(key1|key2)"
}
]
}
}
Is it possible to provide 1 definition that supports both payloads, or do I have to create 2 stubs?
Note: I am using a standalone Wiremock Docker image, so options for more complex handling using Java are limited.
Your JsonPath matcher is formatted incorrectly. You need to apply a filter/script (denoted by ?()). More information about how JsonPath matchers work can be found here.
Here is what the properly formatted JsonPath matcher could look like:
{
"matchesJsonPath": "$[?(#.key1 || #.key2)]"
}
If you need the key1 and key2 to have specific values, that would look like:
{
"matchesJsonPath": "$[?(#.key1 == 'value1' || #.key2 == 'value2')]"
}

How do i convert this code from Dataweave 1 to Dataweave 2

I have to convert some code from dataweave 1 to dataweave 2 but I'm not sure how to convert this patch of code. The answers I found online are confusing
I'm not sure if these two maps are syntaxed the right way, or the syntax for filtering then mapping. I know you have to convert flowVars to vars
flowVars.referenceDataResponse.resultSets filter $.schemaSequenceNumber == "TRESIDENCE_TYPE" map (resultSets,indexOfResultSets) -> {
(resultSets.resultSet map (resultSet,indexOfResultSet) -> {
residenceType:resultSet[indexOfResultSet].data
} )
}
You should really give more context, like inputs, expected output and the directives of the script but this is a literal translation, with output set to application/java because of lack of anything else:
%dw 2.0
output application/java
---
vars.referenceDataResponse.resultSets filter $.schemaSequenceNumber == "TRESIDENCE_TYPE" map (resultSets, indexOfResultSets) -> {
(resultSets.resultSet map (resultSet, indexOfResultSet) -> {
residenceType: resultSet[indexOfResultSet].data
})
}
No way to know if it works for you, given that there is no test data.
Alejandro,
I have Posted sample data, may help to test your suggested conversion solution and I have assumed resultSet is an object with two attribute. You may improve the data to cater your suggested solution
%dw 2.0
output application/json
var arr =
referenceDataResponse: {
resultSets :
[
{
id: 1,
schemaSequenceNumber :"TRESIDENCE_TYPE",
resultSet: [{residenceType: "one"},{residenceType: "two"},{residenceType: "three"}]
},
{
id: 2,
schemaSequenceNumber :"TRESIDENCE_TYPE2",
resultSet:[{residenceType: "one"},{residenceType: "two"},{residenceType: "three"}]
},
{
id: 3,
schemaSequenceNumber :"TRESIDENCE_TYPE3",
resultSet:[{residenceType: "one"},{residenceType: "two"},{residenceType: "three"}]
}
]
}
---
arr.referenceDataResponse.resultSets filter $.schemaSequenceNumber == "TRESIDENCE_TYPE" map (resultSets, indexOfResultSets) -> {
(resultSets.resultSet map (resultSet, indexOfResultSet) -> {
residenceType: resultSet.residenceType
})
}

REST, cross-references and performances, which compromise?

After reading this excellent thread REST Complex/Composite/Nested Resources about nested structures in REST responses, I still have a question. What's the best choice in terms of performance about the response ?
Let's take an example.
I have an Category object, which contains some Questions. Those Questions contains some Answers. All of these structures have meta-informations.
Now, when querying an url like GET http://<base_url>/categories/, should I include a description of the Categories only, include Question description ? Which one, full description or simplified one ?
In other terms, what's the best solution between those :
{
"results":[
{
'id':1,
'name':'category1',
'description':'foobar',
'questions':[
{
'id':1234,
'question':'My question',
'author' : 4235345,
'answers':[
{
'id':56786,
'user':456,
'votes':6,
'answer':'It's an answer !'
},
{
'id':3486,
'user':4564,
'votes':2,
'answer':'It's another answer !'
},
]
},
...
]
}
...
]
}
OR SOLUTION 2 :
{
"results":[
{
'id':1,
'name':'category1',
'description':'foobar',
'questions':[
{
'id':1234,
'url':'http://foobar/questions/1234'
'answers':[
{
'id':56786,
'url':'http://foobar/answers/56786'
},
{
'id':3486,
'url':'http://foobar/answers/3486'
},
]
},
...
]
}
...
]
}
OR SOLUTION 3 :
{
"results":[
{
'id':1,
'name':'category1',
'description':'foobar',
'questions':'http://foobar/categories/1/questions'
}
...
]
}
Or maybe another solution ?
Thanks !
That depends on what the application will do with the data. If it is only going to display a list of categories, then it is very inefficient to transfer all the data it ever needs at once, especially if the categories are many, which will decrease response time of user (absolute no no).
These scenarios depend heavily on application and usage of data.
One optimization that we can do is, we can create two requests,
GET http://<base_url>/categories
Which will return minimal data immediately and another request,
GET http://<base_url>/categories?all=true
Which will return all data.
Then the client app can make some clever optimizations like, when user requests for categories, request one is sent and it will immediately render the data. Then after getting the list of categories the user will be idle for some time looking and we can use this opportunity to request all data using request two.
However, as I said this will largely depend on the application.

Does it make sense to use internal anchors for filtering a REST API's representation?

As a follow up to my previous question about REST URIs for retrieving statistical information for a web forum Resource, I want to know if it is possible to use the internal anchors as filter hints. See example below:
a) Get all statistics:
GET /group/5t7yu8i9io0op/stat
{
group_id: "5t7yu8i9io0op",
top_ranking_users: {
[ { user: "george", posts: 789, rank: 1 },
{ user: "joel", posts: 560, rank: 2 } ...]
},
popular_topics: {
[ ... ]
},
new_topics: {
[ ... ]
}
}
b) GET only popular topics
GET /group/5t7yu8i9io0op/stat#popular_topics
{
group_id: "5t7yu8i9io0op",
popular_topics: {
[ ... ]
}
}
c) GET only top ranking users
GET /group/5t7yu8i9io0op/stat#top_ranking_users
{
group_id: "5t7yu8i9io0op",
top_ranking_users: {
[ { user: "george", posts: 789, rank: 1 },
{ user: "joel", posts: 560, rank: 2 } ...]
}
}
Or should I be using query parameters ?
Not sure what you are trying to do exactly, but make sure you understand that fragment identifiers are not seen by the server, they are chopped off by the client connector.
See: http://www.nordsc.com/blog/?p=17
I've never seen anchors being used that way - it's interesting. That being said, I'd suggest using query parameters for a couple of reasons:
They're standard - and consumers of your api will be comfortable with them. There's nothing more annoying that dealing with a quirky api.
Many frameworks will auto-parse the query parameters and set them in a dictionary on the request object (or whatever analogue exists in your framework / http server library).
I think it would make more sense to have:
/group/5t7yu8i9io0op/stat/top_users
/group/5t7yu8i9io0op/stat/popular_topics
/group/5t7yu8i9io0op/stat/new_topics
/group/5t7yu8i9io0op/stat/user/george
No you cannot do that because as Jan points out the server will never see that fragment identifier. Literally, that part of the url will not reach the server.