Thanks Ryan. I agree that this workaround is ideal if the schema is under one's control.
However, I am working on an implementation of Avro; my library accepts and emits user-defined Avro schemas, so I really do need to know what is okay according to the spec and the official ASF implementations of Avro. I personally think it is ideal to accept ".MyRecord" as a fullname, and adjust the spec accordingly. It makes sense for me that the grammar for fullnames should be "<namespace>.<bare name>", and indeed "" is a valid namespace, so excluding is more complicated and less elegant. On 2022-08-24 08:42, Ryan Skraba wrote: > Hello! There is definitely an ambiguity here caused by inheriting namespaces. > > The obvious takeaway is to use a namespace with all of your named > schemas. As a best practice, that avoids the problem of mixing > schemas with and without namespaces, and it's probably this techniq > > This same problem occurs in Java classes, where you can have a class > in the default package (without a package name), but it's an error to > import it into other packages. > > The ".MyRecord" notation might be the right way to clarify this, but > we can also go the Java route (i.e. you can't mix namespaced schema > and non-namespaced schemas). What do you think? > > Best regards, Ryan > > > > On Mon, Aug 22, 2022 at 10:49 PM Brennan Vincent <[email protected]> > wrote: >> >> On 2022/08/22 20:05:22 Martin Grigorov wrote: >>> Hi, >>> >>> I might be wrong but I think your sample schema should be valid! Does it >>> fail with any of the SDKs ? >> >> Yes. It fails with the Python avro package. >> >>> >>> This part of the spec talks about the namespace, not the type. I.e. >>> "namespace": ".ns" would be an error. >> >> The linked thread ( >> https://lists.apache.org/thread/q0o58fxgvstvdlgpoyv2pcz53borp587 ) >> is a bit vague -- it's not totally clear whether the restriction is meant to >> apply to >> namespaces only, or to fullnames also. >> >> "The null namespace may not be used in a dot-separated sequence of names." >> >> certainly makes it sound like it applies to _any_ sequence of names, though, >> not just in a namespace field. >> >>> >>> On Mon, Aug 22, 2022 at 10:40 PM Brennan Vincent <[email protected]> >>> wrote: >>> >>>> Hello, >>>> >>>> https://github.com/apache/avro/pull/917 introduced the following language >>>> to the spec: >>>> >>>>> The null namespace may not be used in a dot-separated sequence of names. >>>> >>>> Thus ruling out fullnames like ".foo". >>>> >>>> However, this seems to rule out referring to names in the default >>>> namespace from another namespace. >>>> >>>> For example, this schema was previously allowed by the spec: >>>> >>>> { >>>> "type": "record", >>>> "name": "r", >>>> "fields": [ >>>> { >>>> "name": "f", >>>> "type": { >>>> "type": "record", >>>> "name": "r2", >>>> "namespace": "ns", >>>> "fields": [ >>>> { >>>> "name": "f2", >>>> "type": ["null", ".r"] >>>> } >>>> ] >>>> } >>>> } >>>> ] >>>> } >>>> >>>> Note ".r" in the type of "f2". This can't be changed to "r", >>>> because that would be interpreted as "ns.r" due to "ns" being the nearest >>>> enclosing namespace. >>>> >>>> Thus it seems that the new spec has restricted the set of valid schemas >>>> and there is no longer >>>> any way to accomplish this. >>>> >>>> Am I misinterpreting the spec? Does the empty namespace being disallowed >>>> in dotted sequences >>>> of names only apply to initial name definitions, but not to later name >>>> references? Or is there >>>> some other way to express this? >>>> >>>> Here is the initial discussion of this change, where the issue I'm raising >>>> here doesn't >>>> appear to have come up: >>>> https://lists.apache.org/thread/q0o58fxgvstvdlgpoyv2pcz53borp587 >>>>
