Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Malcolm Greaves
    @malcolmgreaves
    First release is on sonatype: 0.2.5 !
    Benjamin Rizkowsky
    @benoahriz
    :thumbsup:
    Eric Biggs
    @ebiggs
    Thanks for the great avro codegen util. Quick question: why does the Message trait have a type parameter?
    Zbigniew Czapran
    @zczapran
    Hi
    Does anyone know if avro-codegen supports Value Classes in any way?
    Paul Kinsky
    @pkinsky
    @ebiggs: IIRC the message trait has a type param so that a GeneratedMessageCompanion[A] can require that A conform to [A <: GeneratedMessage with Message[A]], this lets it use the toMutable method defined on Message[A] as such:
    def toMutable(msg: A): org.apache.avro.generic.GenericRecord = msg.toMutable
    @zczapran: avro-codegen does not support value classes. In the future I'd like to add support for custom types via something similar to ScalaPB's TypeMapper: https://trueaccord.github.io/ScalaPB/customizations.html
    @ebiggs is currently working on a custom schema parser. When that's done we will be able to augment the avro schema specification to include an optional scalaType that will function similarly to the protobuf annotation used by ScalaPB: [(scalapb.field).type = "mydomain.Seconds"].
    Eric Biggs
    @ebiggs
    ScalaPB's custom base trait is on my wish list!
    Malcolm Greaves
    @malcolmgreaves
    @ebiggs merging once travis finishes and gives the OK
    Malcolm Greaves
    @malcolmgreaves
    Released 0.3.0 which includes @ebiggs 's awesome new feature.
    Malcolm Greaves
    @malcolmgreaves
    So in spectacular fashion.....we forgot to ensure that the actual code generation step uses this new parser XD
    @pkinsky and I will work on this tomorrow and get this sorted out
    (1) make sure that the codegen part uses the new partial schema parser
    (2) have it work with both .avsc and .avsp
    (3) update the end-to-end tests to include partial schemas, verify that they are parsed correctly
    (4) update the .travis.yml to include "sbt test"
    when we fix, we'll release 0.3.1
    Eric Biggs
    @ebiggs
    hah yeah I shoulda mentioned that i didn't do that part!
    hey so does anybody else feel like it might be nice to move the Av* stuff into runtime, and put the string literals as partials into a central file and then replace the long canonical strings in each generated class file with a call to AvModule?
    that way there's no repetition in the string literals.
    Eric Biggs
    @ebiggs
    Regarding your commit message about namespaces, I want to explain what I ran into and maybe we can come up with a better solution... The avro specification makes a distinction between no namespace and the null namespace. The null namespace is referred to by an empty string, And specifying no namespace means to inherit from the parent context. However, if there is no parent context, then use the null namespace. Unfortunately there's no way to distinguish between these two different semantics using the fully qualified name, but the Av* AST does make a distinction. So if you specified namesakes == None, it infers the null namespace and a reference that refers to None will not work.. I think there's probably a way to clean this up I just didn't take the time to think it through and write the tests etc..
    Malcolm Greaves
    @malcolmgreaves
    Paul and I paired today, getting the codegen module to actually use the partial schema parser. Updated the e2e tests to exercise this new behavior. Now 0.3.1 is out which is nice and useable! =D
    wrt to the runtime stuff @ebiggs : I think that could work. It is generated code, though, so I don't know how much of a burden this change will lift off our collective shoulders... You're advocating this just to reduce repetition?
    wrt namespaces: ah, I didn't realize that distinction in the spec
    with that, I think what I had earlier was a test exercising the null namespace...but without actually using null.<name_of_schema>
    so that e2e test case was actually probably wrong to begin with...
    With this new info, I'm not sure if this namespace thing is as important. IMO everyone should put their schemas into namespaces. Maybe we could have an option to fail the codegen if we encounter a schema w/o a namespace?