Enable appending to objects / arrays on ingestion
Matar Peles
Today, when updating new objects / arrays of entities the new value overrides the old one. With this feature it will be possible to append values to these properties.
Example of Tags property with type of array:
Current state:
"Tags" : ["tag1"]
Ingesting a new tag using the API:
"tag2"
New state:
"Tags": ["tag1", "tag2"]
M
Maya Margalit
Merged in a post:
Ability to Aggregate Relations Across Multiple port.yaml Files
Priya Raghu
Currently, when multiple port.yaml files update the same entity, the relations array gets overwritten by the latest update, and any existing relations are lost. It would be helpful if relations from all port.yaml files can be aggregated to maintain a comprehensive list of relationships across projects.
M
Maya Margalit
Merged in a post:
Upsert entity - option to append/detach relationships rather than overwrite
M
Mark Tarry
When performing an entity upsert via automations, API, Terraform, GitHub Actions, etc, any relationship values are overwritten with that specified on the upsert request.
This makes maintaining "many" relationships non-trivial, as now the caller must:
- Fetch the current entity state
- Extract the relationship which are to be modified
- Manipulate the relationship arrays
- Perform the upsert API call
Notice the above requires 2 API calls (GET and PATCH) - meaning that, in any scenario where it's possible to have multiple jobs running in parallel (e.g. automations, event-driven workflows), we also now need some form of "transaction locking" in place, to ensure we don't end up with relations being overwritten from a race condition.
M
Mark Tarry
I've raised a similar suggestion here: https://roadmap.port.io/ideas/p/upsert-entity-option-to-append-detach-relationships-rather-than-overwrite
M
Mark Tarry
I noticed a similar suggestion here: https://roadmap.port.io/ideas/p/ability-to-aggregate-relations-across-multiple-portyaml-files
But this seemed to focus on GitOps data ingestion, whereas I'm focusing on data pushed via the Port API
S
Simon Beaulieu
Relevant use case: Being able to populate define 1:many relationships between entities during mapping from the point of view of the target.
For example, if I have a 1:many relationship between a Github repository and Github branches and I want the Github repository to be the source of the relationship, I cannot possibly know the identifier of all branches in advance. When mapping the branches, having the ability to update the relationship of a repository entity by appending all branch identifiers calculated from the "branch" kind.
This would also circumvent the current documented limitation of 100 results max when attempting to map using search queries.