Do we have some example tests that we can make more thorough so they will
be reasonably exhaustive?
On Mon, Jan 2, 2023 at 1:54 PM Reuven Lax wrote:
> Be very careful with the auto schema stuff around Avro. These classes
> dynamically inspect Avro-generated classes (to codegen schema accessors)
Be very careful with the auto schema stuff around Avro. These classes
dynamically inspect Avro-generated classes (to codegen schema accessors) so
it will be easy to break this in a way that is not seen at compile time.
On Mon, Jan 2, 2023 at 12:17 PM Alexey Romanenko
wrote:
> Here is the recent
Here is the recent update on the progress for this topic.
After receiving a feedback on the design document [1] presented to community
before and having the several discussions after (many thanks for this!), it was
decided to take an “option 4” (“Move Avro from “core” to generic Avro
Since there are no principal objections against the proposed option 2 (extract
Avro-related code from “core” to Avro extension but keep it in “core” for some
time because of transition period), then we will try to move forward and take
this path.
I’m pretty sure that we will face some hidden
@Moritz: I *think* should be fine, and don't have anything specific to
offer for what might go wrong throughout the process. :-) :shrug:
On Fri, Nov 11, 2022 at 2:07 AM Moritz Mack wrote:
> Thanks a lot for the feedback so far! I can only second Alexey. It was
> painful to come to realize
Thanks a lot for the feedback so far! I can only second Alexey. It was painful
to come to realize that the only feasible option seems to be copying a lot of
code during the transition phase.
For that reason, it will be critical to be disciplined about the removal of the
to-be deprecated code in
Thank you for writing this document. It really helps to understand the
options. I agree that option 2 (make a new extension and deprecate from
core) seems best. I think +Reuven Lax might have the
most context on any technical issue we will encounter around schema codegen.
Kenn
On Thu, Nov 10,
Personally, I think that keeping two mostly identical versions of Avro-related
code in two different places (“core" and "extension") is rathe bad practice,
especially, in case of need to fix some issues there - though, it’s a very low
risk there since this code is quite mature and it’s not
Being tied to a specific version of a dependency, and esp. one that is
not-[actually-long-term]critical, sounds like a problem. It doesn't seem
like Avro needs to be in core. I am in favor of about any path someone
wants to address towards removing that from core [ *#2 in the design doc
seems
Any thoughts on this? For now, we'd need to decide which path finally to take
to move forward.
Thanks in advance!
—
Alexey
> On 4 Nov 2022, at 16:44, Alexey Romanenko wrote:
>
> Hi all,
>
> Following-up an Avro dependency update discussion [1] that showed a lot of
> uncertainties to move
Hi all,
Following-up an Avro dependency update discussion [1] that showed a lot of
uncertainties to move forward, Moritz and I decided to create a design document
[2] with potential options, that we believe, can be considered and used
further. Unfortunately, all solutions lead to breaking
11 matches
Mail list logo
