Hi,
I am using AVRO serialization for an internal project.
To improve the build integration, I can contribute:
- Minor improvement to the build task (to advertise list of generated
files)
- Nuget automatic package generation
The later can be easily done using Visual Studio 201
In line with Philip Zeyliger on IDL being a good tool for a human to produce
schema.
Key features (IMHO):
- support for includes (killer feature)
- simpler syntax (a *lot* less '{' and '['...)
- simpler comments syntax
I have a toolchain going from IDL to Java + C# classes that wouldn't work using
The AVRO enum concept is highly impractical to use in real-life scenario (IMHO).
Default value or not, adding an enum value breaks backward/forward
compatibility (and a default value is not going to cut it).
To keep the "enum" concept in my AVRO contracts, I choose to create record that
holds a
Hi,
My wire format for an AVRO message is [fingerpring][AVRO serialization].
The fingerprint is used to lookup the right AVRO schema from something akin
Confluent Schema Registry.
I have a new Perl data producer and could not find fingerprint calculation in
the lib.
Am I missing something obviou
On top of that, cross-language compatibility (at least, C#/Java) is not
supported on the 1.8.x branch.
-Original Message-
From: Andy Coates (JIRA) [mailto:j...@apache.org]
Sent: 23 March 2018 14:14
To: dev@avro.apache.org
Subject: [jira] [Created] (AVRO-2164) Make Decimal a first class ty
I second the "encode the scale in the serialised form".
The scale should be a regular property, not a remnant of database fixed size
columns!
FYI, in my project I had to create a 'ScaledFloat' AVRO type to overcome
Java/C# serialization incompatibility.
The scale is a regular type attribute, all
