Avro format enconding
See original GitHub issueI would like to propose an official Avro encoding schema to be supported by CloudEvents.
I’ve seen a lot of uses cases, in special here in my current project, with Apache Kafka and the many of them were using Avro as the format. Inspired by this Gist (thanks @rbramley), the following schema could be the first draft:
{
"namespace":"io.cloudevents",
"type":"record",
"name":"CloudEvent",
"version": "1",
"doc": "CloudEvents Spec for Avro format encoding (the version is just for the schema itself)",
"fields":[
{
"name":"specversion",
"type":"string"
},
{
"name":"type",
"type":"string"
},
{
"name":"source",
"type":"string"
},
{
"name":"id",
"type":"string",
},
{
"name":"time",
"type":[
"null",
"int"
],
"logicalType": "date"
},
{
"name":"schemaurl",
"type":[
"null",
"string"
]
},
{
"name":"contenttype",
"type":[
"null",
"string"
]
},
{
"name":"data",
"type":[
"null",
"string"
]
},
{
"name":"extensions",
"type":[
"null",
{
"type":"map",
"values":[
"string",
"int",
"long",
"float",
"double",
"boolean",
"bytes"
]
}
]
},
]
}
- Official Avro spec available here
Extensions
To define a top-level extension (like below) is not allowed by Avro spec for avsc
, because we do not have the feature for dynamic fields like JSON. Because of this, you will see the extension
attribute to the example above.
...
"comexampleextension1" : "value",
"comexampleextension2" : {
"othervalue": 5
}
...
For that, we may employ Avro spec for ìdl
that is a higher-level language for authoring Avro schemas.
- Official Avro IDL docs available here
Special Types
What I mean with special types, logical types in JSON Schema, are: uri-reference
. We do not have this type in Avro.
For that, again, we may employ Avro IDL.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:4
- Comments:7 (6 by maintainers)
Ha, came here to file a feature request for Avro myself, it’s there already 😃 I’m not sure where things stand with that format spec, but I’ll be happy to help out with it.
That’s a great idea. Avro and CBOR are the two extra encodings which I’d love to see.
@duglin this would be a different event format, not a different transport.
I’m in favor. Who writes the spec.