Hi Salva,
The easiest way to deal with this is to rename the fields and schemas. This
is best done with an alias containing the previous name: that way, the new
schema can safely read the old data. I understand however, that this does
not scale due to the size of your system.
A second way is to use your own NameValidator implementation (or
NameValidator.NO_VALIDATION, though I'd recommend against that) when
parsing the schemas. This works with the (deprecated) Schema.Parser, and
I'm planning to revise that code to work with the new SchemaParser as well.
Kind regards,
Oscar
On Mon, 31 Mar 2025 at 16:10, Salvadoruve <salvador...@gmail.com> wrote:
> Hi Avro Community,
>
> I recently upgraded from Avro 1.11.3 to the new minor version 1.12.0 and
> ran into an issue with schema parsing. In 1.12.0, it seems there's stricter
> name validation enforced by the following code in the schema parser:
>
> private static final Pattern NAME_PATTERN =
> Pattern.compile("[A-Za-z_][A-Za-z0-9_]*");
> static void validateName(String name, boolean allowNamespace) {}
>
> This change is causing problems with some of our older schemas, which were
> registered with names that don’t conform to this pattern (e.g., names with
> special characters or starting with numbers). These schemas worked fine in
> 1.11.3, but now they fail to parse in 1.12.0.
>
> I have two questions:
>
> 1. Is there a workaround to relax this validation or handle these
> legacy schemas without renaming them? For context, I’m using the Java SDK,
> and modifying all existing schemas isn’t ideal due to the scale of our
> system.
> 2. If no workaround exists, is there any plan to introduce a
> compatibility patch or configuration option in a future release to support
> parsing schemas with less strict name validation?
>
> Any advice or insights would be greatly appreciated! Please let me know if
> you need more details about my setup or the specific schema names causing
> issues.
>
> Thanks,
> Salva V
>
>
--
✉️ Oscar Westra van Holthe - Kind <os...@westravanholthe.nl>
