feat: relations #303

vertex451 · 2025-08-07T14:51:09Z

Resolves #254

Features

Relations are resolved in GetItem only. For ListItem and both subscriptions it is disabled for now. When user try to query related field, he will receive null.
Relation nesting is limited by 1, but in future we can change it to bigger number. Also, nesting level is hardcoded for now, later we can pass it as a user input.
In case of the same kind but different group graphql schema while generated track those conflicts and mark apiGroup and kind fields from user input as required. It is done during startup, so no unnecessary calculation during runtime.

Testing

Tested 15.08 at 44afd8b commit in local-setup

Demo

and CRD:

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

pteich

I left some comments and suggestions.

gateway/resolver/relations.go

gateway/resolver/resolver.go

pteich · 2025-08-15T13:51:36Z

gateway/schema/schema.go

 	}

+	// Initialize the relation enhancer after gateway is created
+	g.relationEnhancer = NewRelationEnhancer(g)


It's the same circular dependency as above. I don't really see a need to separate it in another struct. You don't have an possibility to add a different RelationEnhancer so it makes no sense. I would move the methods to the Gateway. You can however keep it in a separate file.

You are not going to believe - I seen those deps, but decided to go with them since it is in the same package.
But eventually you have the point - no need to move it under a different struct.

listener/pkg/apischema/builder.go

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

aaronschweig · 2025-08-18T07:59:18Z

listener/pkg/apischema/builder.go

+			if schema.VendorExtensible.Extensions == nil {
+				schema.VendorExtensible.Extensions = map[string]any{}
+			}
+			schema.VendorExtensible.Extensions[common.ScopeExtensionKey] = apiextensionsv1.NamespaceScoped
 		} else {
-			schema.VendorExtensible.AddExtension(common.ScopeExtensionKey, apiextensionsv1.ClusterScoped)
+			if schema.VendorExtensible.Extensions == nil {
+				schema.VendorExtensible.Extensions = map[string]any{}
+			}
+			schema.VendorExtensible.Extensions[common.ScopeExtensionKey] = apiextensionsv1.ClusterScoped


Why was this changed, was therer a deprecation somewhere? The old code looked cleaner

Overlooked this comment, now I noticed it, returned AddExtension method.

aaronschweig

A few questions:

How does it verify, that none of the "deep" nesting is provided, as we wanted it to be limited to one level deep?
How is prevented for watches, as with the field resolver we have the ability to execute this query on everything.
How would you solve the multiple kinds for different group errors? E.g. imagine a resource that has a ThingRef but Thing is provied via group A and group B - how would you know which would be the right kind to use for the relation?

aaronschweig · 2025-08-18T08:00:10Z

listener/pkg/apischema/builder.go

+	if crd == nil {
 		return b
 	}

-	schema, ok := b.schemas[getOpenAPISchemaKey(*gvk)]
-	if !ok {
+	gkv, err := getCRDGroupVersionKind(crd.Spec)


was it intentional, that the short path with the categories got removed?

I did this change having in mind different versions of CRD.

Before Categories were applied to the "preferred" version of a CRD
After Categories are applied to ALL versions of a CRD

It is not directly related to the relations feature, but it is needed for consistency.

Let me know if it makes sense for you.

aaronschweig · 2025-08-18T08:00:35Z

listener/pkg/apischema/builder.go

+			if resourceSchema.VendorExtensible.Extensions == nil {
+				resourceSchema.VendorExtensible.Extensions = map[string]any{}
 			}
+			resourceSchema.VendorExtensible.Extensions[common.CategoriesExtensionKey] = apiResource.Categories


Same question as above

I touched this code as well for the same reason, but behavior remains the same compared to main branch - the change is in refactoring, less parsing and early returns.

I was asking more about why the easily readale AddExtension was removed with this custom logic

That was not necessary, returned AddExtension methods instead of manual manipulation.

aaronschweig · 2025-08-18T08:02:55Z

listener/pkg/apischema/builder.go

+		key := strings.ToLower(gvk.Kind)
+		b.kindRegistry[key] = append(b.kindRegistry[key], resourceInfo)


What happens if we have the same kind provided by different groups? We have a bug here. In go map keys can be arbitrary, so it would be more benefitial to use the GroupVersionKind struct as an index here, rather than only the kind, the circumvent future name collisions with the kind.

Especially in the platform-mesh usecase this might be very common, that the same kind is provided form x different apiGroups

you are right - we may have silent overrides here, fixing it.
Fixed

aaronschweig · 2025-08-18T08:04:43Z

listener/pkg/apischema/relationships_test.go

+	// Two schemas with same Kind different groups/versions - first should win
+	first := schemaWithGVK("a.example", "v1", "Thing")
+	second := schemaWithGVK("b.example", "v1", "Thing")
+	b.SetSchemas(map[string]*spec.Schema{
+		"a.example.v1.Thing": first,
+		"b.example.v1.Thing": second,
+		"c.other.v1.Other":   schemaWithGVK("c.other", "v1", "Other"),
+	})


This test is basically testing the exact wrong thing that I mentioned in the other comment - this would in my view be a bug, not intended behaviour

I change a logic a bit - now server preferred resources has priority first, if no, we put in the first place resources from core group, then by version stability (v1 > v1beta1 > v1alpha1).
Logic is preserved in findBestResourceForKind.

And I added a test that checks if server preferred resources comes first.

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

github-actions bot added the feature label Aug 7, 2025

vertex451 force-pushed the relations-new branch from 4928320 to c4e3060 Compare August 14, 2025 11:52

github-actions bot removed the feature label Aug 14, 2025

vertex451 marked this pull request as ready for review August 14, 2025 12:03

vertex451 requested a review from a team as a code owner August 14, 2025 12:03

vertex451 force-pushed the relations-new branch from c4e3060 to ed11c85 Compare August 14, 2025 14:21

github-actions bot added the feature label Aug 14, 2025

feat: relations

ad375ed

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

vertex451 force-pushed the relations-new branch from 19ea7a5 to ad375ed Compare August 15, 2025 08:32

vertex451 added 3 commits August 15, 2025 13:23

removed hardcoded versions

20546e2

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

simplidied buildKindRegistry

249f80a

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

consistentcy

96a22a2

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

vertex451 self-assigned this Aug 15, 2025

vertex451 added this to the 2025.Q3 milestone Aug 15, 2025

pteich requested changes Aug 15, 2025

View reviewed changes

vertex451 added 3 commits August 15, 2025 17:32

resolver

de3c7a5

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

removed circular dep from gateway

0787ae7

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

better sorting

44afd8b

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

vertex451 requested a review from pteich August 15, 2025 15:48

pteich approved these changes Aug 17, 2025

View reviewed changes

aaronschweig reviewed Aug 18, 2025

View reviewed changes

aaronschweig requested changes Aug 18, 2025

View reviewed changes

vertex451 added 6 commits August 18, 2025 11:54

smart sorting with preffered resource first

9f14440

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

use GVK instead of Kind as a kay

5cd1b84

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

add test with preferred resource

a9a360c

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

use map native methods

54b8d92

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

nesting

f286765

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

limit relation resolver by getItem only

c2bca5b

On-behalf-of: @SAP [email protected] Signed-off-by: Artem Shcherbatiuk <[email protected]>

		key := strings.ToLower(gvk.Kind)
		b.kindRegistry[key] = append(b.kindRegistry[key], resourceInfo)

feat: relations #303

Are you sure you want to change the base?

feat: relations #303

Conversation

vertex451 commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Features

Testing

Demo

Uh oh!

pteich left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aaronschweig left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vertex451 Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

vertex451 commented Aug 7, 2025 •

edited

Loading

vertex451 Aug 18, 2025 •

edited

Loading