Avro $ref, documentation and parser

[safetytrick]

The $ref in the Avro documentation is misleading:

https://www.asyncapi.com/docs/specifications/2.0.0/#message-object-example

Specifically:

"$ref": "path/to/user-create.avsc#/UserCreate"

An Avro schema doesn't have this kind of structure, instead the UserCreate record would be represented at this path (jsonpath syntax):

$.types.[?(@.name=='UserCreate')]

Example Avro schema for reference:

https://github.com/spring-cloud/spring-cloud-schema-registry/pull/41/files#diff-f84d47e6ddc1b7ccd0d9fb0bcbae8a3dR4

Expected behavior
The docs should be updated to remove this misleading reference and probably explain the state of the Avro support here (References to elements within an Avro schema aren't possible due to the difference in structure between Avro and asynapi)

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue.

Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[derberg]

@safetytrick you mean it should be "$ref": "path/to/user-create.avsc#/$.types.[?(@.name=='UserCreate')]"?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[derberg]

@safetytrick is this still something you are interested with?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[VladT86]

Hi @derberg

I'm having a similar issue while trying to parse an avro schema containing more objects definitions. What is the proper syntax to select one of the objects from the avsc file that has attributes of other object types defined in the same avsc file?

Thanks

[derberg]

@dalelane @M3lkior hi folks, did you try more complex references to Avro files? you have some examples?

[dalelane]

My interpretation of this, and how I've been using it, was that the $ref specifies

• location of the schema file
• fully-qualified name of the record in the schema file
  (separated by #/)

(And I only include the name of the record where the schema file contains more than one record - typically, I try to keep the avsc file containing a single definition, and in those cases I would just point the $ref at the avsc file without additional qualification).

But, in the rare occasions where I need to point at an avsc file containing multiple records, such as the example specified I would've written

"$ref": "path/to/user-create.avsc#/org.springframework.cloud.schema.avro.User1"

I hadn't considered using jsonpath to identify where in the avsc file the schema lives - I've just fully-qualified the name of the schema I want to use, as this is consistent with how I reference other Avro schemas within an Avro schema file.

But I've been using this for user-readable documentation purposes, and haven't yet tried running this through the parser to see what it would do.

[dalelane]

FYI - There is also a related discussion about being more consistent with JSON schema in how we use $ref in #649

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️