dditional external component is too strict a
> > restriction (as much as there are completely valid reasons for it to be a
> > recommendation).
> >
> > And, with a very small modification to the avro formatter, it’s a
> > restriction we could remove.
> >
> > Kin
estriction
> we could remove.
>
> Kind regards
>
> Dale
>
>
>
> From: Ryan Skraba
> Date: Monday, 30 October 2023 at 16:42
> To: dev@flink.apache.org
> Subject: [EXTERNAL] Re: [DISCUSS] Confluent Avro support without Schema
> Registry access
> Hello! I to
October 2023 at 16:42
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: [DISCUSS] Confluent Avro support without Schema
Registry access
Hello! I took a look at FLINK-33045, which is somewhat related: In
that improvement, the author wants to control who registers schemas.
The Flink job would know the
as describing)
>
> Kind regards
>
> Dale
>
>
>
> From: Martijn Visser
> Date: Friday, 27 October 2023 at 14:03
> To: dev@flink.apache.org
> Subject: [EXTERNAL] Re: [DISCUSS] Confluent Avro support without Schema
> Registry access
> Hi Dale,
>
> I&#
issues if you
needed to mix-and-match with both formatters at the same time? (Rather than
just using the Avro formatter as I was describing)
Kind regards
Dale
From: Martijn Visser
Date: Friday, 27 October 2023 at 14:03
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: [DISCUSS] Confluen
Hi Dale,
I'm struggling to understand in what cases you want to read data
serialized in connection with Confluent Schema Registry, but can't get
access to the Schema Registry service. It seems like a rather exotic
situation and it beats the purposes of using a Schema Registry in the
first place? I
TLDR:
We currently require a connection to a Confluent Schema Registry to be able to
work with Confluent Avro data. With a small modification to the Avro formatter,
I think we could also offer the ability to process this type of data without
requiring access to the schema registry.
What would p
