Query related entities by relation name
planned
Gur Shafriri
Currently, when searching for related entities, all related entities in the blueprint specified will be returned.
This feature will allow for the specification of the relation path, allowing different visualizations to be based on it.
For example, Create separate tables for 2 types of relations to the same entity.
Gur Shafriri
planned
We are now planning the capability of declaring a path to identifier via relation when filtering entities in the API, so that you can define a specific path instead of using the general "related to" filter.
We would love feedback on the syntax proposed in the attached image. Note that defining "blueprint" is required only when going backwards on the graph.
This will also allow new paths that were not available up until now, like changing directions mid-path.
Ervin Varga
Gur Shafriri
Good to hear about this being planned, as it is really a missing feature!
It would be good to base such queries on established industry standards and tools, like JSONPath or jq. Of course, it depends on how multiple JSON files will be joined internally in Port, but proprietary syntax should be avoided as much as possible. I think, basing everything on jq is a promising approach, since it is already integrated into Port in defining calculation properties.
Gur Shafriri
Ervin Varga thanks for sharing feedback!
We had multiple versions of this, some with dotted syntax like json path (.author.team.domain etc) and some with arrows (-> author -> team -> domain) but those got very complicated when building queries in multiple directions (that requires defining the blueprint of the target as well as the relation name).
Do you have an example in mind of how the examples in the image above could be phrased ideally as a known syntax?
Ervin Varga
Gur Shafriri
In case of mimicking JSONPath, you may use a filter expression to specify the blueprint. For example, a relation reference with a blueprint specification may look like as .domain[?(@.blueprint == 'team')]. The idea is to make all these queries familiar to users accustomed to any of the previously mentioned technologies and standards.
Gur Shafriri
exploring
Gur Shafriri
Merged in a post:
In the related entities use the name of the relation in the tab
Kostis Kapelonis
Right now in the related entities tab the name of the target entity is used. This works well for simple cases.
But for more advanced cases where the name of the relationship is important or where multiple relations share the same target entity, it would be best to show the name of the relationship instead of the entity in the tab
Gur Shafriri
Merged in a post:
Allow filtering by relation in tables and graph view
M
Mark-Oliver Junge
In cases where we have 2 blueprints that are related through more than 1 type of edge, it would be extremely useful to filter by the type of relation.
Suppose the attached model, with commits being linked to builds through a single relation (head_commit) and a many relation (commit_history). I would like to be able to on the page for a commit, filter the graph for only builds with that commit as the head commit.
(Sidenote: It would also be nice, if there is 2 edges between 2 nodes to display both. In this example it shows 3 relations as commit_history, but they are also related by head_commit, which is hidden)