A unified read/write/schema codec for Avro values, combining the kindlings-avro-derivation triplet (AvroEncoder[A], AvroDecoder[A], AvroSchemaFor[A]) into a single typeclass that user code summons once per type.
Why an extra wrapper at all? kindlings ships three independent typeclasses so users can encode- only or decode-only — but cats-eo-avro's optics always need both sides to be honest (a Prism's get decodes, its reverseGet / place encodes). Forcing every call site to thread two using parameters is noisy. AvroCodec[A] is the project-internal shorthand.
Why not vulcan? Vulcan 1.13.x pins apache-avro 1.11.5; kindlings-avro-derivation 0.1.2 pins 1.12.1. cats-eo-avro chose kindlings + avro 1.12 because it lines up with the rest of the ecosystem moving forward, and the typeclass surface is simpler (no Either[AvroError, A] threading on every call — kindlings' decoders throw on failure, which the prism layer wraps into AvroFailure).
'''Per the eo-avro plan (OQ-avro-1):''' the codec library at v0.1.0 is com.kubuszok:kindlings-avro-derivation — a choice of derivation BACKEND, not of typeclass surface. A codebase whose codecs are vulcan bridges them into this typeclass instead (issue #73): import dev.constructive.eo.avro.vulcan.given makes every in-scope vulcan.Codec[A] serve as an AvroCodec[A], or name it explicitly via dev.constructive.eo.avro.vulcan.AvroVulcan.codec — see the dev.constructive.eo.avro.vulcan.AvroVulcan scaladoc for the error mapping.
Attributes
- Companion
- object
- Source
- AvroCodec.scala
- Graph
-
- Supertypes
-
class Objecttrait Matchableclass Any