Invalid scala generated for record with 2 fixed types in different namespaces but same schema name

[steve-e]

We have come up against the following problem. If a record has 2 fixed types in different namespaces but same schema name then the code generated does not compile.

Here is an example avro schema dmonstrating the problem

{
  "type": "record",
  "name": "FixedTwo",
  "namespace": "fixedtwo",
  "fields": [
    {
      "name": "first",
      "type": {
        "type": "fixed",
        "name": "fixed",
        "namespace": "fixedtwo.one",
        "size": 16
      }
    },
    {
      "name": "second",
      "type": {
        "type": "fixed",
        "name": "fixed",
        "namespace": "fixedtwo.two",
        "size": 16
      }
    }
  ]
}

Using these typical test settings

    val infile = new java.io.File("avrohugger-core/src/test/avro/fixed_two.avsc")
    val gen = new Generator(SpecificRecord)
    val outDir = gen.defaultOutputDir + "/specific/"
    gen.fileToFile(infile, outDir)

This generates 3 source files

target/generated-sources/specific/fixedtwo/FixedTwo.scala
target/generated-sources/specific/fixedtwo/one/fixed.scala
target/generated-sources/specific/fixedtwo/two/fixed.scala

The fixed classes are in different packages so having the same simple class name is not a problem

$ find . -name fixed.scala
./target/generated-sources/specific/fixedtwo/one/fixed.scala
./target/generated-sources/specific/fixedtwo/two/fixed.scala                                                                                                                                       
$ find . -name fixed.scala -exec grep package {}  \;
package fixedtwo.one
package fixedtwo.two

However, the FixedTwo record class imports both fixed classes

/** MACHINE-GENERATED FROM AVRO SCHEMA. DO NOT EDIT DIRECTLY */
package fixedtwo

import scala.annotation.switch

import fixedtwo.two.fixed

import fixedtwo.one.fixed

final case class FixedTwo(var first: fixed, var second: fixed) extends org.apache.avro.specific.SpecificRecordBase {

This causes a compilation error as the name fixed is ambiguous.

[julianpeeters]

thanks again for the report, @steve-e

Possible solutions:
as I see it,

• a short term solution would likely be simply to ensure that the fields of the class definition are generated using fully qualified names
• long term would likely entail an investment in the avrohugger's import system: a way to pass custom renaming, and an error if renaming is needed

[julianpeeters]

My own timeframe is pretty far out, currently, but happy to help with what I can:

Background: regarding avrohugger's import system,

• its goal was to make the generated code more human readable (imo, an unwarranted bias, in retrospect)
• avrohugger's initial use-cases were simple (hence there was little attention paid to conflicting names)
• it has always been buggy (e.g., over-generating Optimize imports on file generation #92)

Current Status: Slowly replacing the import system by instead generating fully qualified names (e.g., here, and here)

• feature space is huge though, and AFAIK there are still no tools for property testing
• ideally an import system will be reintroduced, but IMO first a simplification of is likely necessary

[julianpeeters]

fixed by #191