[ https://issues.apache.org/jira/browse/AVRO-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17569915#comment-17569915 ]
Oscar Westra van Holthe - Kind commented on AVRO-530: ----------------------------------------------------- {quote}If the define-before-use rule were removed for schemas in general, then it would have to be added to Parsing Canonical Form for Schemas, so that schema fingerprints stay the same as before even if the subschemas can now be defined in a different order.{quote} Would it make sense to define the Parsing Canonical Form for Schemas on the schema objects, rather than their JSON sources? The way I read the subsection "[Transforming into Parsing Canonical Form|https://avro.apache.org/docs/1.11.0/spec.html#Transforming+into+Parsing+Canonical+Form]", the fields to serialise, their order and how to serialise them are fully defined. This would make it near-trivial to rewrite this from a JSON transformation into a JSON serialisation. The advantage of that would be that after parsing (and resolving any forward references), the parsing canonical form of a schema would remain exactly the same as before forward references existed. > allow for mutual recursion in type definitions > ---------------------------------------------- > > Key: AVRO-530 > URL: https://issues.apache.org/jira/browse/AVRO-530 > Project: Apache Avro > Issue Type: Improvement > Components: spec > Affects Versions: 1.3.2 > Reporter: Jeff Hodges > Priority: Major > > Suppose you have these two types in your protocol: > {code} > {"name": "User", "type": "record", "fields": [{"name": "current_status", > "type": "Status"}]} > {"name": "Status", "type": "record", "fields": [{"name": "author", "type": > "User"}]} > {code} > This will raise an error! The current workaround is to define one of them at > their first usage. Like: > {code} > {"name": "User", "type": "record", "fields": [{"name": "current_status", > "type": {"name": "Status", "type": "record", "fields": [.. lots of fields > ...]}]} > {code} > But this is incredibly unwieldy. It would be really nice for the spec to > require all the parsers to allow for mutual recursion, instead. It could be > done by implementing a two-pass parser. One pass to acquire names referenced, > and a second to fill in those names with their appropriate references. -- This message was sent by Atlassian Jira (v8.20.10#820010)