Here is the JSON Response:
[{
"startTime": "2020-07-21T15:20:00.000+00:00",
"endTime": "2020-07-21T15:40:00.000+00:00",
"availabilities": [{
"availabilityId": "eyJJZCI6MTA4N",
"startTime": "2020-07-21T15:20:00.000+00:00",
"endTime": "2020-07-21T15:40:00.000+00:00",
"channel": "PHONE",
"programId": "Msff",
"providerDetails": {
"firstName": "abc",
"lastName": "abc",
"providerTitle": "NURSE"
}
}]
}, {
"startTime": "2020-07-21T15:40:00.000+00:00",
"endTime": "2020-07-21T16:00:00.000+00:00",
"availabilities": [{
"availabilityId": "eyJJZCI6MTA4NDM2MiwiU3RhcnRUa",
"startTime": "2020-07-21T15:40:00.000+00:00",
"endTime": "2020-07-21T16:00:00.000+00:00",
"channel": "PHONE",
"programId": "Msff",
"providerDetails": {
"firstName": "def",
"lastName": "def",
"providerTitle": "NURSE"
}
}]
}]
And here is the check i am using to extract the first "availabilityId" from json response
check(
jsonPath("$[0][availabilities].[0].availabilityId") saveAs "availabilityId"
)
but i am getting error:
jsonPath($[0][availabilities].[0].availabilityId).find.exists extraction crashed: end of input expected
I validated the path on https://jsonpath.com/, i am able to see the result. What am i doing wrong?
That's an example of how bad JsonPath is in its current state:
JsonPath currently doesn't have a real specification
because of holes in the original "paper" (a simple blog post actually) and implementors going with their own interpretation and likings, there are A LOT of differences between implementations
jsonpath.com isn't currently a reference, just someone who bought the domain name
Here, if you check the original source, you'll see that the square notation is supposed to use single quotes to wrap field name:
JSONPath expressions can use the dot–notation
$.store.book[0].title
or the bracket–notation
$['store']['book'][0]['title']
What happens here is that the Gatling implementation sticks to this definition while the JavaScript one used on jsonpath.com allows for ditching the single quotes.
Also, you shouldn't have dots between your brackets, so your path should be:
$[0]['availabilities'][0].availabilityId
You could also stick to the more common dot notation:
$[0].availabilities[0].availabilityId
There's an ongoing effort on creating a proper JsonPath implementation. Until this effort lands, we from Gatling recommend going with JMESPath instead, as explained here. On contrary to JsonPath atm, JMESPath has a real complete grammar and a compliance test suite.
You have added unnecessary square brackets. Change jsonPath on:
$.[0].availabilities.[0].availabilityId
Related
Ok, so this is going to be a complicated question, I hope I'm clear. Full admission, I just finished a Bootcamp yesterday so I'm not aware of a lot of technologies out there, and I think I may need additional technologies to accomplish what I'm looking for...
Right now, I have an application that uses bandsintown API call to populate a database. What I've noticed is that bandsintown isn't consistent with their data returns in each object, which makes operations after retrieving the objects difficult/seemingly impossible. An example would be that different artists performing at the same venue returns different latitude, longitude, venue name, etc. Examples:
Here is Primus playing at Bonnaroo:
{
"offers": [],
"venue": {
"country": "United States",
"city": "Manchester",
"latitude": "35.4839582",
"name": "Bonnaroo Music and Arts Festival 2020",
"location": "",
"region": "TN",
"longitude": "-86.08963169999998"
},
"datetime": "2020-09-25T12:00:00",
"on_sale_datetime": "",
"description": "",
"lineup": [
"Primus"
],
"bandsintown_plus": false,
"id": "1020701795",
"title": "",
"artist_id": "1263",
"url": "https://www.bandsintown.com/e/1020701795?app_id=451f31b2808001d069daed45c32a9dac&came_from=267&utm_medium=api&utm_source=public_api&utm_campaign=event"
}
compared to The Weeknd playing at Bonnaroo:
{
"id": "18604416",
"url": "https://www.bandsintown.com/e/18604416?app_id=451f31b2808001d069daed45c32a9dac&came_from=267&utm_medium=api&utm_source=public_api&utm_campaign=event",
"datetime": "2017-05-17T19:00:00",
"title": "",
"description": "",
"venue": {
"location": "",
"name": "Bonnaroo",
"latitude": "35.476247",
"longitude": "-86.081026",
"city": "Manchester",
"country": "United States",
"region": "TN"
},
"lineup": [
"The Weeknd"
],
"offers": [],
"artist_id": "1371750",
"on_sale_datetime": "",
"bandsintown_plus": false
}
My issue is now I wish to aggregate and $group in MongoDB because both events were at Bonnaroo, but the Object{venue.name} is not the same... Even the latitude & longitude is different so I can't use those either. I'm wondering if there is a way to alter the data of the objects automatically without having to go into the DB and edit individual objects. Both these events include the word Bonnaroo, so could I have something find and match text and then slice out the text that isn't similar? If so, can I then use the matched venue name field as a reference to change the latitude & longitude values too?
I hope I was clear, feel free to ask any clarifying questions if I wasn't. This site has helped me so many times and I appreciate all the hard work the community puts in to help each other! Thanks ahead of time!
~~~EDIT~~~
Thanks for the first reply #morad takhtameshloo.
So I was able to build something before I saw your reply that splits the data into an array, which is along the same lines as what you offered. The only thing that won't work is the $arrayToElem with the index cause there are some venues that:
Have multiple-word names (e.g. The Stone Pony)
Have words before the actual venue name (saw it in one result that was like
"Verizon Live Presents at The Stony Pony")
Using this Bonnaroo example, I have the new field returning every word as a value in the array:
"venueName": ["Bonnaroo", "Music", "and","Arts","Festival","2020"]
My next step is going to be to compare the [venueName] of the 'Primus' object and the 'The Weeknd' object, find what values in the array are the same, and return them back to the value of "venueName".
Hope this makes more sense, I appreciate your input!
actual the trick depends to your data, you should provide more data if the ones you've provided does not depict the whole problem
in other words how deep you want to dive in.
for the dumbest answer, at least for the data you've provided
db.prod4.aggregate([
{
$addFields: {
venueName: {
$arrayElemAt: [{ $split: ['$venue.name', ' '] }, 0],
},
},
},
])
but that not the case of course, something that comes to mind is that venue's geolocations for the same venue should not be far away from each other, for instance, the data you've provided two locations are in 1.16 KM of each other.
so another dummy solution that works would be writing a simple script that selects a random element from the array of all data, and finds data that their lat/lng is for example in 2km of that point, and removes those elements from array and selects another random element from the array and do the same
if you provide more data it would be much more easier, because the easiest solution is to find many patterns and plan only for them
How can I define an array object property, that contains several items in a comma separated string in openapi-v3?
I want to validate a request body (not query parameter!) like this:
{
"friends": "Ann,Bob"
}
I am dreaming of an openApi v3 schema definition like this one:
"friends": {
"type": "array",
"items": {
"type": "string",
"enum": [
"Ann",
"Bob",
"Charlie"
]
},
"commaSeparation": ",", // does not exist
}
Is there a officially supported way to describe such string contents? If not: What could be a workaround, that still precisely defines and validates those texts?
No, there is not. Unfortunately to the parser friends is and will always be a string.
You could add a pattern regex to enforce the contents, something like:
"friends": {
"type": "string",
"pattern": "[Ann|Bob|Charlie],+" // some regex that enforces the allowed tokens and a trailing comma
}
If you want a real array, then you need to use an array type.
Using the example document that Solr has:
{
"ID": "1",
"title": "Solr adds block join support",
"content_type": "parentDocument",
"comments": [{
"ID": "2",
"content": "SolrCloud supports it too!"
},
{
"ID": "3",
"content": "New filter syntax"
}
]
},
When I try to index this json, it would give this error: "ERROR: [doc=1] unknown field 'comments.ID'" even though the field ID is defined in the schema (of course, comments.ID is not)
I am trying to use the labelled relationship and not the anonymous relationship using _childDocuments_ because that is what the docs recommends. What am I missing?
If you're trying to send this to the /update/json/docs convenience path, it will likely fail with a nested document.
Try instead to send your document to the /update path, and use the JSON command structure shown here https://solr.apache.org/guide/8_11/uploading-data-with-index-handlers.html#sending-json-update-commands
Basically, send to /update and wrap your document in an
{
"add": {
"doc": {<your document here>}
}
}
Be sure to also set the content type to application/json
Google's Structured Data Testing Tool doesn't seem to like JSON-LD's #language in value object approach to string internationalization. For example:
{
"#context": "https://schema.org/",
"#type": "Person",
"name": [{"#language": "ar", "#value": "أياس"},
{"#language": "en", "#value": "Eyas"}]
}
or
{
"#context": "https://schema.org/",
"#type": "Person",
"name": {"#language": "ar", "#value": "أياس"}
}
don't seem to work. I also tried adding "#type": "Text" but that doesn't seem to make it happy either.
Is there an accepted way of specifying multiple language representations of the same thing in Schema.org JSON-LD that is respected by search engines?
I know there's "inLanguage" for certain types, but that is not general enough to, e.g., work with a Person.
I'm trying to standartize a property in a json-ld document. A simple example:
json-ld
{
"#context": {
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"dcterms": "http://purl.org/dc/terms/"
},
"#graph": [
{
"#id": "1",
"rdfs:label": "A title"
},
{
"#id": "2",
"dcterms:title": "Another title"
}
]
}
frame (failing attempt)
{
"type": "array",
"items": {
"title": ["rdfs:label", "dcterms:title"]
}
}
This produces an empty graph, instead of this:
desired output
[{
"title": "A title"
},
{
"title": "Another title"
}]
The documentation at https://json-ld.org/primer/latest/#framing seems to be work in progress and there is really not a lot of examples or tutorials covering json-ld framing.
Playground example
Framing is used to shape the data in a JSON-LD document, using an example frame document which is used to both match the flattened data and show an example of how the resulting data should be shaped
https://json-ld.org/spec/latest/json-ld-framing/#framing
This beeing said, re-shaping data does not mean you can change the semantics. rdfs:label and dcterms:title are different things in the source data and will be different things in the result, you can not merge them to a "title" property that expands to only one URI (which one?). If that were the case, the result would have different semantics than the source, but framing is only meant to change the structure.