[
https://issues.apache.org/jira/browse/AVRO-3904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcos updated AVRO-3904:
-------------------------
Description:
When calculating the *schema compatibility can read* (schema A can read or not
an event written using a schema B) we expect a *true* or *false* result, but in
some cases the code *panics with a message* (reason of schema not being
compatible) which I think it should not.
Example:
{code:js}
let schema_1 = Schema::parse_str(
r#"{
"type": "record",
"name": "StatisticsMap",
"fields": [
{"name": "success", "type": {"type": "map", "values": "int"}}
]
}"#)?;
let schema_2 = Schema::parse_str(
r#"{
"type": "record",
"name": "StatisticsMap",
"fields": [
{"name": "success", "type": ["null", {"type": "map", "values": "int"}],
"default": null}
]
}"#)?
assert!(SchemaCompatibility::can_read(&schema_1, &schema_2)); # true as expected
assert!(SchemaCompatibility::can_read(&schema_2, &schema_1)); # expected result
false!!
The application panicked (crashed).
Message: internal error: entered unreachable code: writers_schema should have
been Schema::Map
{code}
PS: If the intention is to give feedback to end users when schemas are not
compatible then it makes sense the panic (maybe a Result should be better?) but
the feedback should be present in every time that the result is false, which is
not the case.
I have a PR ready to fix this in case that we want to change the current
behaviour
was:
When calculating the *schema compatibility can read* (schema A can read or not
an event written using a schema B) we expect a *true* or *false* result, but in
some cases the code *panics with a message* (reason of schema not being
compatible) which I think it should not.
Example:
{code:js}
let schema_1 = Schema::parse_str(
r#"{
"type": "record",
"name": "StatisticsMap",
"fields": [
{"name": "success", "type": {"type": "map", "values": "int"}}
]
}"#)?;
let schema_2 = Schema::parse_str(
r#"{
"type": "record",
"name": "StatisticsMap",
"fields": [
{"name": "success", "type": ["null", {"type": "map", "values": "int"}],
"default": null}
]
}"#)?
assert!(SchemaCompatibility::can_read(&schema_1, &schema_2)); # true as expected
assert!(SchemaCompatibility::can_read(&schema_2, &schema_1));
The application panicked (crashed).
Message: internal error: entered unreachable code: writers_schema should have
been Schema::Map
{code}
PS: If the intention is to give feedback to end users when schemas are not
compatible then it makes sense the panic (maybe a Result should be better?) but
the feedback should be present in every time that the result is false, which is
not the case.
I have a PR ready to fix this in case that we want to change the current
behaviour
> [rust] Sometimes when calculating schema compatibility the code panics but
> maybe it should not
> ----------------------------------------------------------------------------------------------
>
> Key: AVRO-3904
> URL: https://issues.apache.org/jira/browse/AVRO-3904
> Project: Apache Avro
> Issue Type: Improvement
> Reporter: Marcos
> Priority: Major
>
> When calculating the *schema compatibility can read* (schema A can read or
> not an event written using a schema B) we expect a *true* or *false* result,
> but in some cases the code *panics with a message* (reason of schema not
> being compatible) which I think it should not.
> Example:
> {code:js}
> let schema_1 = Schema::parse_str(
> r#"{
> "type": "record",
> "name": "StatisticsMap",
> "fields": [
> {"name": "success", "type": {"type": "map", "values": "int"}}
> ]
> }"#)?;
> let schema_2 = Schema::parse_str(
> r#"{
> "type": "record",
> "name": "StatisticsMap",
> "fields": [
> {"name": "success", "type": ["null", {"type": "map", "values": "int"}],
> "default": null}
> ]
> }"#)?
> assert!(SchemaCompatibility::can_read(&schema_1, &schema_2)); # true as
> expected
> assert!(SchemaCompatibility::can_read(&schema_2, &schema_1)); # expected
> result false!!
> The application panicked (crashed).
> Message: internal error: entered unreachable code: writers_schema should
> have been Schema::Map
>
> {code}
> PS: If the intention is to give feedback to end users when schemas are not
> compatible then it makes sense the panic (maybe a Result should be better?)
> but the feedback should be present in every time that the result is false,
> which is not the case.
> I have a PR ready to fix this in case that we want to change the current
> behaviour
--
This message was sent by Atlassian Jira
(v8.20.10#820010)