Validation for relationships fails on valid case

[wtrocki]

Problem with OpenVolunteerModel

Error: Volunteer.actions and VolunteerAction.volunteer 'key' annotations are different. Ensure both are the same or remove one so that it can be generated.

https://github.com/aerogear/OpenVolunteerPlatform/blob/master/platform/server/model/main.graphql#L38-L41

The action doesn't have a key specified and ManyToOne side has (this was just copied from the generated schema for visibility of the field in the schema)

Error is confusing as key is not there. Removing key from manyToOne will fix it.

[machi1990]

/cc @craicoverflow, @machi1990
Automatically generated comment to notify maintainers

[wtrocki]

I'm not sure if there is some fix here.

[wtrocki]

This is a bug. Little bit debugging showed me that result schema has some extra annotations generated and ends up with 2 annotations under single object:

[wtrocki]

So trick that I have done is:

• Generate schema
• When to schema to take generated fields and include them into model (they should be ok to be in the model.
• Generate code:

<b>Generation failed: Error: Volunteer.actions and VolunteerAction.volunteer 'key' annotations are different. Ensure both are the same, or remove one so that it can be generated.</b>

[wtrocki]

See also #2020

[craicoverflow]

What happens when you remove all manyToOne annotations from the data model? It should succeed

[wtrocki]

It will fail validation (unless this change is applied)

[craicoverflow]

Can you show me the output?

[craicoverflow]

Can you reproduce this error using the models from the templates? They are smaller and more focused so it is easier to see why the error occurs - as in OVP the model is large and there could be other schema errors.

[machi1990]

So trick that I have done is:

• Generate schema
• When to schema to take generated fields and include them into model (they should be ok to be in the model.
• Generate code:

<b>Generation failed: Error: Volunteer.actions and VolunteerAction.volunteer 'key' annotations are different. Ensure both are the same, or remove one so that it can be generated.</b>

I think this

graphback/packages/graphback-core/src/relationships/RelationshipMetadataBuilder.ts

Line 292 in 5201457

if (oneToManyMetadata?.key !== corresspondingManyToOneMetadata?.key) {

will need changing so that it compares the two keys if they are both defined (read as user defined values) since if they are not defined they'll be generated with key info:

• graphback/packages/graphback-core/src/relationships/RelationshipMetadataBuilder.ts

  Line 226 in 5201457

  // skip - relationship with key annotation will be generated at later stage

• graphback/packages/graphback-core/src/relationships/RelationshipMetadataBuilder.ts

  Line 248 in 5201457

  // skip - relationship with key mapping will be generated at a later stage

• graphback/packages/graphback-core/src/relationships/RelationshipMetadataBuilder.ts

  Line 205 in 5201457

  if (!oneToManyAnnotation.key) {

What's your thoughts on this @craicoverflow ?

[craicoverflow]

will need changing so that it compares the two keys if they are both defined (read as user defined values)

That sounds better - this way you could have a manyToOne annotation with the key property and it would get updated, am I right?

I think these patches we make to RelationshipBuilder will not make the class any easier to work with, and I wonder whether #2023 should be focused on, as this particular issue raised I don't think is the root of the problem.

[machi1990]

will need changing so that it compares the two keys if they are both defined (read as user defined values)

That sounds better - this way you could have a manyToOne annotation with the key property and it would get updated, am I right?

I think these patches we make to RelationshipBuilder will not make the class any easier to work with, and I wonder whether #2023 should be focused on, as this particular issue raised I don't think is the root of the problem.

+1 on this.

[craicoverflow]

Closing as the case was valid and working as intended (it actually caught an invalid relationship association in the model). There is an issue #2023 to track a general improvement of relationships.