Apicurio / apicurio-registry

An API/Schema registry - stores APIs and Schemas.
https://www.apicur.io/registry/
Apache License 2.0
609 stars 269 forks source link

Reference "name" field expects a package #3490

Closed derickmr closed 1 year ago

derickmr commented 1 year ago

When creating a new PROTOBUF artifact which contains references, the "name" field of the reference expects me to inform the package of my import instead of the actual field name. To make things clearer, find below an example.

curl -X POST http://localhost:8080/apis/registry/v2/groups/default/artifacts \ -H 'Content-Type: application/create.extended+json' \ -H "X-Registry-ArtifactId: my.test.Example" \ -H 'X-Registry-ArtifactType: PROTOBUF' \ --data-raw '{ "content": "syntax = \"proto3\";\n\npackage my.test;\n\nimport \"my/test/another_example.proto\";\n\nmessage Example {\n string item_id = 1;\n string item_name = 2;\n string item_type = 3;\n my.test.AnotherExample another_example = 4;\n}", "references": [ { "groupId": "default", "artifactId": "my.test.AnotherExample", "name": "my/test/another_example.proto", "version": 1 } ] }'

Note that the "name" field of the reference is my/test/another_example.proto, which is the package that field, instead of another_example, which is the actual field name.

I'd expect that the value of that field should match name of the field, instead of its package, as below:

... "references": [ { "groupId": "default", "artifactId": "my.test.AnotherExample", "name": "another_example", "version": 1 } ] ...

I did a little bit of debugging on this, and it seems that the dependencies are resolved by package in your FileDescriptorUtils: https://github.com/Apicurio/apicurio-registry/blob/main/utils/protobuf-schema-utilities/src/main/java/io/apicurio/registry/utils/protobuf/schema/FileDescriptorUtils.java#L1146 (note: I can be wrong about this being the root cause)

For reference, I am running Apicurio Registry on KSQL 2.4.2.Final version.

carlesarnal commented 1 year ago

Hi @derickmr,

The reference name must be something that allows the client application to fully resolve the referenced schema. That is why, in this case, you have the complete package + the field type and, e.g., for avro, you have the fully qualified schema name. Do you mind elaborating a bit more on the actual problem you're facing with this approach or why you think this is not the correct one?

Thanks!