How to represent responses with heterogenous arrays in pact-jvm - pact

I'm having trouble figuring out how to represent arrays with structurally different objects in an array in pact contracts.
From pact-spec-v3
It would also be required to define whether the matchers should be
combined with logical AND (all matchers must match) or OR (at least
one matcher must match). AND should be the default, but there are
cases where an OR makes sense
Can this be leveraged to 'OR' the two different types of objects ?
This is the response that I'm trying to model via the pact-jvm DSL, the suggestions array contains two objects of different types, '1' and '3', having different schemas -
{
"suggestions": [
{
"display_name": "Potato",
"type": 1,
"keyword": "Potato",
"category_l1": {
"icon_image_url": "XXXXX",
"id": 1489,
"name": "Potato"
}
},
{
"type": 3,
"suggestion": {
"display_name": "New Potato (Aloo)",
"name": "New Potato"
}
}
]
}
Code that I have so far:
private DslPart getBody() {
return new PactDslJsonBody()
.eachLike("suggestions", 1)
.stringType("display_name")
.integerType("type")
.stringType("keyword")
.object("category_l1")
.stringType("icon_image_url")
.stringType("name")
.integerType("id")
.closeObject()
.closeObject()
.closeArray();
}

This is not currently easy to model with Pact, it works assuming each item is similar to a provided example. For a discussion, see https://github.com/pact-foundation/pact-specification/issues/38

Related

openAPI-specification: what is the type of the variable when one of them is given in the AdditionalProperties?

I am new to OpenAPI-specifications and I was confused about the type of a variable when the attribute additionalProperties is used.
For example at https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md#schemaObject we see the example
{
"type": "object",
"additionalProperties": {
"type": "string"
}
}
What is the type of this now? Is it a string or an object? I do not see how it can be both of them.
thanks in advance, Koen
In this context, the additionalProperties keyword is used to define dictionaries/maps. type: object represents the dictionary itself, and the additionalProperties keyword defines the type of values in the dictionary. The key type is not mentioned because the keys are always strings.
A more general explanation is that additionalProperties is used to allow or deny extra properties not explicitly defined in the properties and patternProperties sections. If extra properties are allowed, additionalProperties specifies their value type.
The example is your post represents a simple string-to-string dictionary, or an object with arbitrary properties whose values are strings, such as:
{
"foo": "bar",
"hello": "world"
}
Similarly, a string-to-integer dictionary is defined as:
{
"type": "object",
"additionalProperties": {
"type": "integer"
}
}
This schema represents objects such as:
{
"apples": 3,
"oranges": 5
}
If the additionalProperties keyword does not specify a type, this means a free-form object with arbitrary properties and values.
{
"type": "object",
"additionalProperties": {}
}
// In OpenAPI 3.x, this can also be written as
{
"type": "object",
"additionalProperties": true
}
For additional info and examples, see:
Dictionaries, HashMaps and Associative Arrays on swagger.io
Additional Properties in the Understanding JSON Schema guide
Why additionalProperties is the way to represent Dictionary/Map in OpenAPI
Swagger Editor dictionary parameter definition
Swagger complex response model with dynamic key value hash maps

filtering Dynamo DB in Step functions JSONPath

I am trying to build a step function that has a choice state based on a map in a result of a dynamo db map. An example result from my dynamo GetItem request would be.
{
"Item": {
"organisationId": {
"S": "Andys-test"
},
"id": {
"S": "Andy2"
},
"states": {
"L": [
{
"M": {
"year": {
"N": "2021"
},
"status": {
"S": "started"
}
}
},
{
"M": {
"year": {
"N": "2022"
},
"status": {
"S": "started"
}
}
}
]
},
},
My condition will be checking the status of the states map against the year 2021. I have attempted to use this JSONPath which from what I can tell is valid, although I am getting nothing in the data flow simulator in the step functions console. I have tried various iterations of the below, with quotes escaped quotes etc and can't get anything to parse the correct value out.
I have been doing this in the input selector as I can see that the result path does not support the [?()] notation.
$.Item.states.L..M[?(#.year.N == 2022) ]
Without an example choice state with some rules, it'll be hard to answer definitively but I think I'm following.
JSONPath with expression filters
I run into this sort of problem more often than I'd like when using JSONPath filter expressions and have to add "helper" tasks to get things moving (wasting valuable state transitions 😣 ).
When you specify a Path that includes a filter expression, the result is always going to be a list (and you won't be able to reference index afterwards either).
ChoiceRules don't really have a comparator that deals with arrays/lists (at least i haven't been able to get it to work, so let me know if you do 😄).
The hack I've found easiest to reason about/maintain is creating a simple Pass Task that "pops" the values I need from the filter expression and then pass that along to the Choice Task.
Here's an example from one of my previous answers (the pattern used in the PassDef task would be defined before your choice task in your scenario, instead of after)
I've found it easier to start with https://jsonpath.herokuapp.com then progress to the data flow simulator. Just remember to always keep in mind whether
you're trying implement a Path or a Reference Path!

Azure Cosmos SQL - working with nested arrays and using LIKE keyword

For some time when I had to find particular element of array by particular value I've been using ARRAY_CONTAINS function. Now I have documents with nested arrays where I have to search not but particular value, but using regex.
As an example of document let me use one from official documentation:
{
"id": "AndersenFamily",
"lastName": "Andersen",
"parents": [
{ "firstName": "Thomas" },
{ "firstName": "Mary Kay"}
],
"children": [
{
"firstName": "Henriette Thaulow",
"gender": "female",
"grade": 5,
"pets": [{ "givenName": "Fluffy" }]
}
],
"address": { "state": "WA", "county": "King", "city": "Seattle" },
"creationDate": 1431620472,
"isRegistered": true
}
What I need is to select and fully get all documents where at least one of children has at least one pets element where givenName contains "fluf".
What SQL query do I build to achieve it?
Here's a query that uses JOINs to flatten out the inner pets arrays and apply a filter, then return the entire matching family items:
SELECT VALUE f
FROM Families f
JOIN c IN f.children
JOIN p IN c.pets
WHERE p.givenName LIKE "%Fluf%"
The complexity of figuring out such queries is one reason why I think it's worth considering modeling data to be as flat as possible, including normalizing out to have separate pets items for example, which can be queried with direct property filters without dealing with nesting. Combining everything into a large Family object as the examples do isn't necessarily a good idea in practice depending on your goals.

Is it sensible to create an object id from two dependent push ids?

I have the following exemplary data structure:
"peopleOfFame": {
"asd456789": {
"firstName": "John",
"lastName": "Wayne",
"dateOfBirth": "19660702"
"marriedTo": "yxc321lkj"
},
"yxc321lkj": {
"firstName": "Jennifer",
"lastName": "Aniston",
"dateOfBirth": "19620228"
"marriedTo": "asd456789"
}
},
"relationshipsAmongstPeopleOfFame": {
"asd456789yxc321lkj": {
"asd456789": true,
"yxc321lkj": true,
"datingSince": "20170729",
"children": "0",
"happy": true
},
"yxc321lkj": {
"asd456789asd456789": true,
"yxc321lkj": true,
"datingSince": "20170729",
"children": "0",
"happy": true
}
}
Is there any downside to using the combined ids of the peopleOfFame as the id for the objects in relationshipsAmongstPeopleOfFame?
I feel like this is a good use case where our life would be easier and queries would be faster doing it this way. I've read a ton about data structures in Firebase and I have not come across those examples yet. Neither in a way that encourage them nor discourage them.
Obviously, we have limited use when the number of potential ids grows. But I am talking about clear cut cases where two stored objects form another single stored object.
So, in summary, my question would be: Can you provide me with counter arguments as to why this approach is not good? Or can you encourage me and show me further use cases for this? I feel like there is not a lot out there with those specific 2 objects => 1 object examples.

Querying Freebase to get all relations between two concepts

I'd like to query Freebase in order to obtain all the relations that occur between two concepts.
My problem is that I'd like to do this using two concepts' names.
For example: I have "Ball" as a concept (and I don't want to say to Freebase if it is Ball as in Dance or as in Sports Equipment) and I want to find out if there are relations between it and "Football" (in this case, there is just one concept on Freebase for Football, so it is easier); the ouput should be "/sports/sports_equipment/sport_used_for".
For now I just managed to do the same query using the id of the concepts, but I would like to search for relations as I explained before, without knowing the exact meaning of the concept title (Ball in the example).
The query that I have so far is this:
{
"type": "/type/link",
"source": {
"id": "/m/0dpm1v"
},
"master_property": null,
"target": {
"id": "/m/02vx4"
}
}
Thank you in advance for the help
"name" was what I was looking for. I don't know because I did not try/find this before.
Thak you anyway.
{
"type": "/type/link",
"source": {
"name": "ball"
},
"master_property": null,
"target": {
"name": "football"
}
}

Resources