[jira] [Commented] (AVRO-2843) PHP submit package on packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870178#comment-17870178 ] Martin Tzvetanov Grigorov commented on AVRO-2843: - I've asked the Apache Thrift team to add me/us to Packagist.org apache/ team - https://lists.apache.org/thread/2jkk1qjdwwzfvjn5pywv6dll2pkwm9rk > PHP submit package on packagist.org > --- > > Key: AVRO-2843 > URL: https://issues.apache.org/jira/browse/AVRO-2843 > Project: Apache Avro > Issue Type: Bug > Components: php >Affects Versions: 1.10.0 >Reporter: Siad Ardroumli >Assignee: Ryan Skraba >Priority: Major > Fix For: 1.11.0 > > > Related to AVRO-2752: > Please submit the "apache/avro" package on > [https://packagist.org/packages/submit] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[
https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870164#comment-17870164
]
Martin Tzvetanov Grigorov commented on AVRO-2752:
-
{code:java}
The vendor name "apache" was already claimed by someone else on
Packagist.org. You may ask them to add your package and give you
maintainership access. If they add you as a maintainer on any package in
that vendor namespace, you will then be able to add new packages in
that namespace. The packages already in that vendor namespace can be
found at apache.If those packages belong to you but were submitted by someone
else, you can contact us to resolve the issue. {code}
Someone has registered the `apache` namespace but it is not the ASF Infra team
... We'll have to find out who owns it!
Here is how the Thrift composer.json looks like:
[https://github.com/apache/thrift/blob/438fc822ffc10f85dc7d7a7d05a0f038231f458d/composer.json#L44-L57]
[~jjatria] do you want to send a PR that updates Avro's composer.json ?
We are very close to release 1.12.0 (it is being voted at dev@) and I am not
sure whether we can point [https://packagist.org/packages/submit] at some Git
tag url ...
> PHP: Setup as Composer package on Packagist.org
> ---
>
> Key: AVRO-2752
> URL: https://issues.apache.org/jira/browse/AVRO-2752
> Project: Apache Avro
> Issue Type: Improvement
> Components: php
>Reporter: Ben Edmunds
>Assignee: Siad Ardroumli
>Priority: Major
> Fix For: 1.10.0
>
>
> Composer is the de facto package manager for PHP. Not having Avro available
> as a Composer package on Packagist.org means that this library is impossible
> to use as a direct dependency in most PHP projects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870161#comment-17870161 ] Martin Tzvetanov Grigorov commented on AVRO-2752: - Here is how it works to build the project - [https://github.com/apache/avro/blob/main/lang/php/build.sh#L61-L67] It uses `composer install -d "../.."`. But [https://packagist.org/packages/submit] expects a url like [https://github.com/apache/avro] and this is why the composer.json needs to be in the root ... Now someone has to explain how does it find about lang/php/lib ... > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Assignee: Siad Ardroumli >Priority: Major > Fix For: 1.10.0 > > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870159#comment-17870159 ] Martin Tzvetanov Grigorov commented on AVRO-2752: - I am not a PHP user ... Why the composer.json is at the root of the project ([https://github.com/apache/avro/blob/main/composer.json)] ? How does it know that the sources are in lang/php/lib/** ? > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Assignee: Siad Ardroumli >Priority: Major > Fix For: 1.10.0 > > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-2752) PHP: Setup as Composer package on Packagist.org
[ https://issues.apache.org/jira/browse/AVRO-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17870153#comment-17870153 ] Martin Tzvetanov Grigorov commented on AVRO-2752: - There is nothing about `publishing PHP` at [https://cwiki.apache.org/confluence/display/AVRO/How+To+Release] . Maybe this is the reason ?! I guess someone from the Avro PMC team has to create an account at [https://packagist.org/] and upload releases when they are made. > PHP: Setup as Composer package on Packagist.org > --- > > Key: AVRO-2752 > URL: https://issues.apache.org/jira/browse/AVRO-2752 > Project: Apache Avro > Issue Type: Improvement > Components: php >Reporter: Ben Edmunds >Assignee: Siad Ardroumli >Priority: Major > Fix For: 1.10.0 > > > Composer is the de facto package manager for PHP. Not having Avro available > as a Composer package on Packagist.org means that this library is impossible > to use as a direct dependency in most PHP projects. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AVRO-3617) [C++] Integer overflow risks with Validator::count_ and Validator::counters_
[
https://issues.apache.org/jira/browse/AVRO-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov updated AVRO-3617:
Fix Version/s: 1.12.0
Assignee: (was: Christophe Le Saec)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> [C++] Integer overflow risks with Validator::count_ and Validator::counters_
>
>
> Key: AVRO-3617
> URL: https://issues.apache.org/jira/browse/AVRO-3617
> Project: Apache Avro
> Issue Type: Bug
> Components: c++
>Reporter: Kalle Niemitalo
>Priority: Minor
> Labels: pull-request-available, pull-requests-available
> Fix For: 1.12.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> In Validator, there seems to be some inconsistency with {{std::vector
> counters_}} and {{int64_t count_}}:
> - Validator::countingSetup converts int64_t to size_t:
> {{counters_.push_back(static_cast(count_));}}
> - Validator::countingAdvance converts size_t to int: {{int count =
> --counters_.back();}}
> - Validator::unionAdvance converts size_t to int64_t: {{if (count_ <
> static_cast(node->leaves()))}}
> - Validator::unionAdvance converts int64_t to int and that to size_t:
> {{setupOperation(node->leafAt(static_cast(count_)));}}
> I did not verify whether these integers can actually grow so high that
> overflow is possible. Nevertheless, it would be safest to use integer types
> consistently.
> (Originally posted as
> [https://github.com/apache/avro/pull/1836#issuecomment-1225303643].)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-4021) Pass in build architecture explicitly
[ https://issues.apache.org/jira/browse/AVRO-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17868281#comment-17868281 ] Martin Tzvetanov Grigorov commented on AVRO-4021: - [~fokko] This is fixed in 1.12.0, right ? > Pass in build architecture explicitly > - > > Key: AVRO-4021 > URL: https://issues.apache.org/jira/browse/AVRO-4021 > Project: Apache Avro > Issue Type: Improvement >Reporter: Fokko Driesprong >Assignee: Fokko Driesprong >Priority: Major > Labels: pull-request-available > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3631) Fix serialization of structs containing Fixed fields
[
https://issues.apache.org/jira/browse/AVRO-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3631.
-
Fix Version/s: 1.12.0
1.11.4
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
> Fix serialization of structs containing Fixed fields
>
>
> Key: AVRO-3631
> URL: https://issues.apache.org/jira/browse/AVRO-3631
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Reporter: Rik Heijdens
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Consider the following minimal Avro Schema:
> {noformat}
> {
> "type": "record",
> "name": "TestStructFixedField",
> "fields": [
> {
> "name": "field",
> "type": {
> "name": "field",
> "type": "fixed",
> "size": 6
> }
> }
> ]
> }
> {noformat}
> In Rust, I might represent this schema with the following struct:
> {noformat}
> #[derive(Debug, Serialize, Deserialize)]
> struct TestStructFixedField {
> field: [u8; 6]
> }
> {noformat}
> I would then expect to be able to use `apache_avro::to_avro_datum()` to
> convert an instance of `TestStructFixedField` into an `Vec` using an
> instance of `Schema` initialized from the schema listed above.
> However, this fails because the `Value` produced by `apache_avro::to_value()`
> represents `field` as an `Value::Array` rather than a
> `Value::Fixed<6, Vec` which does not pass schema validation.
> I believe that there are two options to fix this:
> 1. Allow Value::Array> to pass validation if the array has
> the expected length, and none of the contents of the array are out-of-range
> for u8. If we go down this route, the implementation of `to_avro_datum()`
> will have to take care of converting Value::Int to u8 when converting into
> bytes.
> 2. Update `apache_avro::to_value()` such that fixed length arrays are
> converted into `Value::Fixed>` rather than `Value::Array`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3675) [c++] segmentation fault when creating resolving decoder
[ https://issues.apache.org/jira/browse/AVRO-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3675. - Resolution: Not A Problem > [c++] segmentation fault when creating resolving decoder > > > Key: AVRO-3675 > URL: https://issues.apache.org/jira/browse/AVRO-3675 > Project: Apache Avro > Issue Type: Bug > Components: c++ >Affects Versions: 1.11.1 >Reporter: Mitja P >Priority: Major > Labels: pull-request-available > Attachments: data_schema.json, reader_schema.json, validating.cc > > Time Spent: 10m > Remaining Estimate: 0h > > We added a new field to our schema but resolving decoder consistently causes > segmentation fault. > Our new field is an array of records that also have a field that is an array > of records. > See attached schemas and demo code to reproduce. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-4019) [C++] Correct signedness of validator methods
[ https://issues.apache.org/jira/browse/AVRO-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-4019. - Fix Version/s: 1.12.0 Assignee: Gerrit Birkeland Resolution: Fixed > [C++] Correct signedness of validator methods > - > > Key: AVRO-4019 > URL: https://issues.apache.org/jira/browse/AVRO-4019 > Project: Apache Avro > Issue Type: Improvement > Components: c++ >Reporter: Gerrit Birkeland >Assignee: Gerrit Birkeland >Priority: Major > Labels: c++, pull-request-available > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Issue for documenting signedness correction made with > https://github.com/apache/avro/pull/2966 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-2598) C++ standard of library implies C++ standard of projects using Avro
[
https://issues.apache.org/jira/browse/AVRO-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-2598.
-
Fix Version/s: 1.12.0
Resolution: Fixed
> C++ standard of library implies C++ standard of projects using Avro
> ---
>
> Key: AVRO-2598
> URL: https://issues.apache.org/jira/browse/AVRO-2598
> Project: Apache Avro
> Issue Type: Bug
> Components: c++
>Affects Versions: 1.9.0, 1.9.1
>Reporter: Marcel Pfütze
>Priority: Major
> Fix For: 1.12.0
>
>
> SInce Avro 1.9.0 there is an if macro in a lot of headers that uses the
> current C++ standard.
> If you build the library from source and use it in another project with a
> different C++ standard this can lead to segfaults.
> Example of macro:
> {code:c++}
> template T& GenericDatum::value() {
> return (type_ == AVRO_UNION) ?
> #if __cplusplus >= 201703L
> std::any_cast(_)->datum().value() :
> *std::any_cast(_);
> #else
> boost::any_cast(_)->datum().value() :
> *boost::any_cast(_);
> #endif
> {code}
> In our case we build the library from source (which uses the c+11 by default)
> and used it in a project using C+17. There's very little indication to the
> user why the crash happens.
> My proposals:
> * Move implementation from header to source file so that the used standard
> is decided at build time.
> * Use the [CMAKE_CXX_STANDARD
> |https://cmake.org/cmake/help/v3.1/variable/CMAKE_CXX_STANDARD.html]
> functionality provided by cmake to set the standard. In this way the standard
> can also easily set when building the code without actually manipulating the
> CMakeLists.txt file. Of course the --std=c++11
> [here|https://github.com/apache/avro/blob/89218262cde62e98fcb3778b86cd3f03056c54f3/lang/c%2B%2B/CMakeLists.txt#L55]
> can be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-4004) [Rust] Canonical form transformation does not strip the logicalType
[
https://issues.apache.org/jira/browse/AVRO-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-4004.
-
Fix Version/s: 1.12.0
1.11.4
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
> [Rust] Canonical form transformation does not strip the logicalType
>
>
> Key: AVRO-4004
> URL: https://issues.apache.org/jira/browse/AVRO-4004
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Reporter: Dominik Mautz
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The Rust implementation of for the canonical transformation does not strip
> the _logicalType_ as required by the [STRIP] rule
> ([https://avro.apache.org/docs/1.11.0/spec.html#Transforming+into+Parsing+Canonical+Form]).
> This results in different fingerprints for the same schema compared to other
> implementations (at least for Python and Java)
> This is for instance can become an issue for the kafka-delta-ingest
> ([https://github.com/delta-io/kafka-delta-ingest]).
> Rust
> {code:java}
> [package]
> name = "avro issue"
> version = "0.2.0"
> edition = "2018"
> [dependencies]
> apache-avro = "0.16.0"
> anyhow = "1.0.86"
> {code}
> {code:java}
> use anyhow::Result;
> use apache_avro::{rabin::Rabin, Schema};
> use sha2::Sha256;
> fn main() -> Result<()> {
> let schema_str = r#"
> {
> "type": "record",
> "name": "test",
> "fields": [
> {"name": "a", "type": "long", "default": 42, "doc": "The field
> a"},
> {"name": "b", "type": "string", "namespace": "test.a"},
> {"name": "c", "type": "long", "logicalType": "timestamp-micros"}
> ]
> }"#;
> let schema = Schema::parse_str(schema_str)?;
> let canonical_form = schema.canonical_form();
> let fp_rabin = schema.fingerprint::();
> println!("Canonical form: {}", canonical_form);
> println!("Rabin fingerprint: {}", fp_rabin);
> Ok(())
> }
> {code}
> Output:
> {code:java}
> Canonical form:
> {"name":"test","type":"record","fields":[{"name":"a","type":"long"},{"name":"b","type":"string"},{"name":"c","type":{"type":"long","logicalType":"timestamp-micros"}}]}
> Rabin fingerprint: 28cf0a67d9937bb3
> {code}
> As you can see, the _logicalType_ is still present in the "canonical form."
> Python
> {code:python}
>
> import avro.schema
> schema_str = """
> {
> "type": "record",
> "name": "test",
> "fields": [
> {"name": "a", "type": "long", "default": 42, "doc": "The field
> a"},
> {"name": "b", "type": "string", "namespace": "test.a"},
> {"name": "c", "type": "long", "logicalType": "timestamp-micros"}
> ]
> }"""
> schema = avro.schema.parse(schema_str)
> print(f"Canonical form: {schema.canonical_form}")
> print(f"Rabin fingerprint: {schema.fingerprint().hex()}")
> {code}
> Output:
> {code:java}
> Canonical form:
> {"name":"test","type":"record","fields":[{"name":"a","type":"long"},{"name":"b","type":"string"},{"name":"c","type":"long"}]}
> Rabin fingerprint: 385501e341b00a1c
> {code}
> Java returns the same output as python.
> Imho, I think that changing the line
> [https://github.com/apache/avro/blob/main/lang/rust/avro/src/schema.rs#L2159]
> to
> {code:java}
> //...
> if field_ordering_position(k).is_none() || k == "default" || k == "doc" || k
> == "aliases" || k == "logicalType" {
> //...
> {code}
> should resolve the issue. However, I am unsure if this line should actually
> include more even attributes (other than the currently explicitly stated).
> Nevertheless, the test in
> [https://github.com/apache/avro/blob/fdab5db0816e28e3e10c87910c8b6f98c33072dc/lang/rust/avro/src/schema.rs#L3388]
> must also be adopted to reflect the correct transformation of the canonical
> form and the corresponding fingerprint.
> Rabin: 385501e341b00a1c
> MD5: 384f46367ef8c22dbbf44109b82ff7aa
> SHA-256: 8e72f58f2d84a59d6a08e8db5fdc6484dee35babf33179cea72889ae63083f36
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-4004) [Rust] Canonical form transformation does not strip the logicalType
[
https://issues.apache.org/jira/browse/AVRO-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865438#comment-17865438
]
Martin Tzvetanov Grigorov commented on AVRO-4004:
-
I've discussed the namespace issue with [~opwvhk] at
[https://the-asf.slack.com/archives/CLUD54M1S/p1720775029247449] and he
explained to me that the namespace field should be considered as a custom
attribute for non-named Schemas, i.e. anything but Record, Enum and Fixed.
I'll improve the Rust SDK!
> [Rust] Canonical form transformation does not strip the logicalType
>
>
> Key: AVRO-4004
> URL: https://issues.apache.org/jira/browse/AVRO-4004
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Reporter: Dominik Mautz
>Priority: Major
>
> The Rust implementation of for the canonical transformation does not strip
> the _logicalType_ as required by the [STRIP] rule
> ([https://avro.apache.org/docs/1.11.0/spec.html#Transforming+into+Parsing+Canonical+Form]).
> This results in different fingerprints for the same schema compared to other
> implementations (at least for Python and Java)
> This is for instance can become an issue for the kafka-delta-ingest
> ([https://github.com/delta-io/kafka-delta-ingest]).
> Rust
> {code:java}
> [package]
> name = "avro issue"
> version = "0.2.0"
> edition = "2018"
> [dependencies]
> apache-avro = "0.16.0"
> anyhow = "1.0.86"
> {code}
> {code:java}
> use anyhow::Result;
> use apache_avro::{rabin::Rabin, Schema};
> use sha2::Sha256;
> fn main() -> Result<()> {
> let schema_str = r#"
> {
> "type": "record",
> "name": "test",
> "fields": [
> {"name": "a", "type": "long", "default": 42, "doc": "The field
> a"},
> {"name": "b", "type": "string", "namespace": "test.a"},
> {"name": "c", "type": "long", "logicalType": "timestamp-micros"}
> ]
> }"#;
> let schema = Schema::parse_str(schema_str)?;
> let canonical_form = schema.canonical_form();
> let fp_rabin = schema.fingerprint::();
> println!("Canonical form: {}", canonical_form);
> println!("Rabin fingerprint: {}", fp_rabin);
> Ok(())
> }
> {code}
> Output:
> {code:java}
> Canonical form:
> {"name":"test","type":"record","fields":[{"name":"a","type":"long"},{"name":"b","type":"string"},{"name":"c","type":{"type":"long","logicalType":"timestamp-micros"}}]}
> Rabin fingerprint: 28cf0a67d9937bb3
> {code}
> As you can see, the _logicalType_ is still present in the "canonical form."
> Python
> {code:python}
>
> import avro.schema
> schema_str = """
> {
> "type": "record",
> "name": "test",
> "fields": [
> {"name": "a", "type": "long", "default": 42, "doc": "The field
> a"},
> {"name": "b", "type": "string", "namespace": "test.a"},
> {"name": "c", "type": "long", "logicalType": "timestamp-micros"}
> ]
> }"""
> schema = avro.schema.parse(schema_str)
> print(f"Canonical form: {schema.canonical_form}")
> print(f"Rabin fingerprint: {schema.fingerprint().hex()}")
> {code}
> Output:
> {code:java}
> Canonical form:
> {"name":"test","type":"record","fields":[{"name":"a","type":"long"},{"name":"b","type":"string"},{"name":"c","type":"long"}]}
> Rabin fingerprint: 385501e341b00a1c
> {code}
> Java returns the same output as python.
> Imho, I think that changing the line
> [https://github.com/apache/avro/blob/main/lang/rust/avro/src/schema.rs#L2159]
> to
> {code:java}
> //...
> if field_ordering_position(k).is_none() || k == "default" || k == "doc" || k
> == "aliases" || k == "logicalType" {
> //...
> {code}
> should resolve the issue. However, I am unsure if this line should actually
> include more even attributes (other than the currently explicitly stated).
> Nevertheless, the test in
> [https://github.com/apache/avro/blob/fdab5db0816e28e3e10c87910c8b6f98c33072dc/lang/rust/avro/src/schema.rs#L3388]
> must also be adopted to reflect the correct transformation of the canonical
> form and the corresponding fingerprint.
> Rabin: 385501e341b00a1c
> MD5: 384f46367ef8c22dbbf44109b82ff7aa
> SHA-256: 8e72f58f2d84a59d6a08e8db5fdc6484dee35babf33179cea72889ae63083f36
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-4014) [Rust] Sporadic value-schema mismatch with fixed struct
[
https://issues.apache.org/jira/browse/AVRO-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-4014.
-
Fix Version/s: 1.12.0
1.11.4
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
> [Rust] Sporadic value-schema mismatch with fixed struct
> ---
>
> Key: AVRO-4014
> URL: https://issues.apache.org/jira/browse/AVRO-4014
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Affects Versions: 1.11.3
>Reporter: Matthew Tanous
>Assignee: Martin Tzvetanov Grigorov
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We are trying to Avro encode a structure before writing to Kafka, and when we
> are at high load writing the struct into an Avro writer (we started seeing
> around 2.6% error rates at 500K messages per minute) we start seeing this
> error:
> {code:java}
> Value does not match schema: Reason: Unsupported value-schema
> combination{code}
> This is surprising as the same logic is used to build the record in each
> case, and that record is built using the Avro record type with the same
> schema:
> {code:java}
> Record::new(){code}
> This is the code that is ultimately raising the error, but because it is not
> specifying _which_ value does not match _which_ part of the schema, it is
> extremely difficult to debug.
> {code:java}
> let mut writer = Writer::new(, Vec::new());
> writer
> .append(record) // This will fail if the message and
> schema don't match
> .map_err(|err| Report::msg(err.to_string()))?;{code}
> A simple start would be to add logging of the value and the schema that are
> mismatched to help us debug this issue, as I'm not able to determine if the
> `apache-avro` library is doing something erroneous or our code is breaking in
> some unforeseen way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-4015) avro-cpp does not work with CMake's FetchContent
[ https://issues.apache.org/jira/browse/AVRO-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-4015. - Fix Version/s: 1.12.0 Assignee: Martin Tzvetanov Grigorov Resolution: Fixed > avro-cpp does not work with CMake's FetchContent > > > Key: AVRO-4015 > URL: https://issues.apache.org/jira/browse/AVRO-4015 > Project: Apache Avro > Issue Type: Improvement > Components: build, c++ >Reporter: Michael Bailey >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Currently it is not possible to link Avro-cpp as a dependency to a c++ > project using on FetchContent(). The principle reason is that the include > directories are not properly exposed on the avrocpp and avrocpp_s targets. > One other problem is that the necessary libraries are not linked to the > avrocpp_s target, meaning any attempt to link against that target will result > in linker errors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-1721) Should LogicalTypes introduce schema (in)compatibility and canonical parsing form changes?
[ https://issues.apache.org/jira/browse/AVRO-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863758#comment-17863758 ] Martin Tzvetanov Grigorov commented on AVRO-1721: - [~Ten] : AVRO-4004 > Should LogicalTypes introduce schema (in)compatibility and canonical parsing > form changes? > -- > > Key: AVRO-1721 > URL: https://issues.apache.org/jira/browse/AVRO-1721 > Project: Apache Avro > Issue Type: Improvement > Components: spec >Affects Versions: 1.8.0 >Reporter: Bob Cotton >Priority: Major > > During a recent spike of integrating LogcialTypes into our Avro > wrapper we encountered the the following questions. > 1. Is the addition/removal of a logical to a schema element a backward > breaking change? > 2. Should the canonical parsing form include logical type information? > I understand that the underlying base Avro types are not changing with > the introduction of LogicalTypes. The raw serialized data will be the > same. However the client code dependent on the deserialization may be > subject to breakage. > Let me elaborate on these. > 1. Is the addition/removal of a logical to a schema element a backward > breaking change? > Take for example the UUID logical type. At least in the case of > GenericData, if I change a schema element from a string to a UUID and > I have Converters turned on, existing client code that is expecting a > String to be returned will now have a runtime exception when an > instance of UUID is suddenly returned. > From the client's perspective I've just change the underlying type of > the element. > 2. Should the canonical parsing form (CPF) include logical type information? > If the answer to #1 is yes, then the CPF should also include the > logical type information. > We were wondering if there might be a slightly less strict form of > schema "normalization" and fingerprinting. Currently the > fingerprinting process is based on the CPF. It would be interesting to > introduce the "Normal Parsing Form" (NPF) which retains all the > optional information contained within a schema, but in a normal or > regular way. That way a fingerprint could be determined without having > to script possibly important information, like the LogicalType info. > Interested in your thoughts on these questions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-4005) [Rust] JSON Encoding is not supported
[ https://issues.apache.org/jira/browse/AVRO-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-4005. - Resolution: Incomplete > [Rust] JSON Encoding is not supported > - > > Key: AVRO-4005 > URL: https://issues.apache.org/jira/browse/AVRO-4005 > Project: Apache Avro > Issue Type: New Feature > Components: rust >Reporter: xxchan >Priority: Minor > > In the rust lib, there's no way to read/write with JSON encoding > [https://avro.apache.org/docs/1.11.1/specification/#json-encoding] > > There's an implementation of From/To serde_json::Value, but it's not relevant > (and the implementation itself is dubious) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3687) Rust enum missing default
[
https://issues.apache.org/jira/browse/AVRO-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3687.
-
Fix Version/s: 1.12.0
1.11.4
Resolution: Fixed
> Rust enum missing default
> -
>
> Key: AVRO-3687
> URL: https://issues.apache.org/jira/browse/AVRO-3687
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Affects Versions: 1.11.1
>Reporter: Santiago Fraire Willemoes
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Labels: enum, pull-request-available, rust
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> I cannot seem to find the enum's default attribute as documented [in the
> spec|https://avro.apache.org/docs/1.11.1/specification/#enums:~:text=for%20names).-,default,-%3A%20A%20default%20value]
> I'm trying to create an avdl parser and this is a blocker for me. I was
> wondering if there's a reason for this. Otherwise I can submit a PR, please
> let me know, thanks.
> Code sample:
> {code}
> let schema_str =
> r#"{"name":"Shapes","type":"enum","symbols":["SQUARE","TRIANGLE","CIRCLE","OVAL"],
> "default": "SQUARE"}"#;
> let r = Schema::parse_str(schema_str).unwrap();
> let can = r.canonical_form();
> println!("{r:?}");
> println!("{can}");
> {code}
> Observe the enum in its canonical form is missing the default.
> Looking at the Enum's code, we cannot see a default field:
> https://github.com/apache/avro/blob/master/lang/rust/avro/src/schema.rs#L113-L119
> I apologize if this is somehow wrong
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (AVRO-3687) Rust enum missing default
[
https://issues.apache.org/jira/browse/AVRO-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov reopened AVRO-3687:
-
Assignee: Martin Tzvetanov Grigorov
> Rust enum missing default
> -
>
> Key: AVRO-3687
> URL: https://issues.apache.org/jira/browse/AVRO-3687
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Affects Versions: 1.11.1
>Reporter: Santiago Fraire Willemoes
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Labels: enum, pull-request-available, rust
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> I cannot seem to find the enum's default attribute as documented [in the
> spec|https://avro.apache.org/docs/1.11.1/specification/#enums:~:text=for%20names).-,default,-%3A%20A%20default%20value]
> I'm trying to create an avdl parser and this is a blocker for me. I was
> wondering if there's a reason for this. Otherwise I can submit a PR, please
> let me know, thanks.
> Code sample:
> {code}
> let schema_str =
> r#"{"name":"Shapes","type":"enum","symbols":["SQUARE","TRIANGLE","CIRCLE","OVAL"],
> "default": "SQUARE"}"#;
> let r = Schema::parse_str(schema_str).unwrap();
> let can = r.canonical_form();
> println!("{r:?}");
> println!("{can}");
> {code}
> Observe the enum in its canonical form is missing the default.
> Looking at the Enum's code, we cannot see a default field:
> https://github.com/apache/avro/blob/master/lang/rust/avro/src/schema.rs#L113-L119
> I apologize if this is somehow wrong
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-4011) Schema generated via AvroSchema is not compatible with itself
[
https://issues.apache.org/jira/browse/AVRO-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-4011.
-
Fix Version/s: 1.12.0
1.11.4
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
Thanks for confirming!
0.17 should be released in the coming days:
https://lists.apache.org/thread/cncfgrmrzwxho3ywfq6qppnxz9938kn0
> Schema generated via AvroSchema is not compatible with itself
> -
>
> Key: AVRO-4011
> URL: https://issues.apache.org/jira/browse/AVRO-4011
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Affects Versions: 1.11.3
> Environment: Rust 1.79.0
>Reporter: Marco Lugo
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Fix For: 1.12.0, 1.11.4
>
>
> We encountered an issue where our Avro schema generated with the AvroSchema
> macro is not compatible with itself. That is, the
> [can_read|https://docs.rs/apache-avro/latest/apache_avro/schema_compatibility/struct.SchemaCompatibility.html#method.can_read]
> function fails to read the generated schema. Here's a minimal reproducible
> example:
> {code:c}
> use apache_avro::AvroSchema;
> #[derive(AvroSchema)]
> struct Foo {
> a: Vec,
> b: Vec,
> }
> #[derive(AvroSchema)]
> struct Bar {
> value: i32,
> }
> #[cfg(test)]
> mod tests {
> use super::*;
> #[test]
> fn schema_reflexivity() {
> let schema = Foo::get_schema();
> println!("{}", _form());
> assert_eq!(, );
>
> assert!(apache_avro::schema_compatibility::SchemaCompatibility::can_read(,
> )); // this fails
> }
> }
> {code}
> This is with the only dependency in Cargo.toml being:
> {code:java}
> apache-avro = { version = "0.16.0", features = ["derive"] }
> {code}
> The automatically generated Avro schema is:
> {code:json}
> {
> "name": "Foo",
> "type": "record",
> "fields": [
> {
> "name": "a",
> "type": {
> "type": "array",
> "items": {
> "name": "Bar",
> "type": "record",
> "fields": [
> {
> "name": "value",
> "type": "int"
> }
> ]
> }
> }
> },
> {
> "name": "b",
> "type": {
> "type": "array",
> "items": "Bar"
> }
> }
> ]
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-4010) Avoid resolving schema on every call to read()
[ https://issues.apache.org/jira/browse/AVRO-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-4010. - Fix Version/s: 1.12.0 1.11.4 Assignee: Martin Tzvetanov Grigorov Resolution: Fixed > Avoid resolving schema on every call to read() > -- > > Key: AVRO-4010 > URL: https://issues.apache.org/jira/browse/AVRO-4010 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Affects Versions: 1.11.3 >Reporter: Michael Spector >Assignee: Martin Tzvetanov Grigorov >Priority: Major > Labels: pull-request-available > Fix For: 1.12.0, 1.11.4 > > Time Spent: 40m > Remaining Estimate: 0h > > `ResolvedSchema::try_from()` is called from within `Reader::read()`, which > can be easily avoided if resolved schema is cached along with writer schema > once initialized. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-4011) Schema generated via AvroSchema is not compatible with itself
[
https://issues.apache.org/jira/browse/AVRO-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862674#comment-17862674
]
Martin Tzvetanov Grigorov commented on AVRO-4011:
-
Could you please try with 0.17 (from `main` branch). There were many
improvements in the schema_compatibility.rs code that are not yet released.
> Schema generated via AvroSchema is not compatible with itself
> -
>
> Key: AVRO-4011
> URL: https://issues.apache.org/jira/browse/AVRO-4011
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Affects Versions: 1.11.3
> Environment: Rust 1.79.0
>Reporter: Marco Lugo
>Priority: Minor
>
> We encountered an issue where our Avro schema generated with the AvroSchema
> macro is not compatible with itself. That is, the
> [can_read|https://docs.rs/apache-avro/latest/apache_avro/schema_compatibility/struct.SchemaCompatibility.html#method.can_read]
> function fails to read the generated schema. Here's a minimal reproducible
> example:
> {code:c}
> use apache_avro::AvroSchema;
> #[derive(AvroSchema)]
> struct Foo {
> a: Vec,
> b: Vec,
> }
> #[derive(AvroSchema)]
> struct Bar {
> value: i32,
> }
> #[cfg(test)]
> mod tests {
> use super::*;
> #[test]
> fn schema_reflexivity() {
> let schema = Foo::get_schema();
> println!("{}", _form());
> assert_eq!(, );
>
> assert!(apache_avro::schema_compatibility::SchemaCompatibility::can_read(,
> )); // this fails
> }
> }
> {code}
> This is with the only dependency in Cargo.toml being:
> {code:java}
> apache-avro = { version = "0.16.0", features = ["derive"] }
> {code}
> The automatically generated Avro schema is:
> {code:json}
> {
> "name": "Foo",
> "type": "record",
> "fields": [
> {
> "name": "a",
> "type": {
> "type": "array",
> "items": {
> "name": "Bar",
> "type": "record",
> "fields": [
> {
> "name": "value",
> "type": "int"
> }
> ]
> }
> }
> },
> {
> "name": "b",
> "type": {
> "type": "array",
> "items": "Bar"
> }
> }
> ]
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-1521) Inconsistent behavior of Perl API with 'boolean' type
[
https://issues.apache.org/jira/browse/AVRO-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-1521.
-
Fix Version/s: 1.12.0
Assignee: José Joaquín Atria (was: John Karp)
Resolution: Fixed
> Inconsistent behavior of Perl API with 'boolean' type
> -
>
> Key: AVRO-1521
> URL: https://issues.apache.org/jira/browse/AVRO-1521
> Project: Apache Avro
> Issue Type: Bug
> Components: perl
>Reporter: John Karp
>Assignee: José Joaquín Atria
>Priority: Major
> Fix For: 1.12.0
>
>
> The perl boolean serialization code in BinaryEncoder.pm encodes anything
> false to perl, such as 0, '0', '', () and undef, as false, and anything true
> to perl, which is literally everything else, as true.
> Inconsistent with the above serialization, the code used in Schema.pm to
> determine which union branch to use, is checking for boolean-ness with:
> {noformat}
> m{yes|no|y|n|t|f|true|false}i
> {noformat}
> meaning only those particular strings are considered booleans.
> So all those values, including 'no' 'n' 'f' and 'false', still get serialized
> to true.
> We could just standardize on one of the two and use it consistently. But
> neither works that well in unions, because unless you put the boolean type
> last in the union definition, a wide variety of data will be downcast to
> boolean type.
> Perl has no built-in or standardized boolean type, so there's no solution
> like we have in the other language Avro APIs. But we could do as the perl
> JSON module does, and define objects for true and false.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-1517) Unicode strings are accepted as bytes and fixed type by perl API
[
https://issues.apache.org/jira/browse/AVRO-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov updated AVRO-1517:
Fix Version/s: 1.12.0
(was: 1.9.0)
Assignee: José Joaquín Atria (was: John Karp)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Unicode strings are accepted as bytes and fixed type by perl API
>
>
> Key: AVRO-1517
> URL: https://issues.apache.org/jira/browse/AVRO-1517
> Project: Apache Avro
> Issue Type: Bug
> Components: perl
>Reporter: John Karp
>Assignee: José Joaquín Atria
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: AVRO-1517.patch
>
>
> By default in perl, a string is a sequence of bytes, values 0-255. However,
> if a Unicode character is included that cannot be represented with a single
> byte, the string gets 'upgraded' to a non-byte-based Unicode string allowing
> ordinals outside that range. When string operations are done with byte and
> non-byte Unicode strings, the result is always non-byte, with the byte string
> first 'upgraded'. Upgrading consists of utf8 encoding and setting a utf8 flag
> on the string. ('utf8' is a variant of UTF-8 used by perl)
> The perl Avro API is accepting these Unicode strings as-is for the 'bytes'
> type. This is a problem because 1) values >255 are not valid as bytes, and
> any encoding is their job. 2) As Avro assembles the serialized data, perl
> 'upgrades' all the data, having the effect of utf8 encoding our serialized
> binary data.
> The correct behavior is for the Avro perl API is to attempt to downgrade the
> string, and if this fails because of contained values >255 then to raise an
> error. (The behavior of 'string' won't change, it will still take Unicode
> strings as expected.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-1463) Undefined values cause warnings when unions with null serialized
[
https://issues.apache.org/jira/browse/AVRO-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov updated AVRO-1463:
Fix Version/s: 1.12.0
(was: 1.9.0)
Assignee: José Joaquín Atria (was: John Karp)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Undefined values cause warnings when unions with null serialized
>
>
> Key: AVRO-1463
> URL: https://issues.apache.org/jira/browse/AVRO-1463
> Project: Apache Avro
> Issue Type: Bug
> Components: perl
>Reporter: John Karp
>Assignee: José Joaquín Atria
>Priority: Minor
> Fix For: 1.12.0
>
> Attachments: AVRO-1463.patch
>
>
> This code produces warnings:
> {noformat}
> $enc = '';
> $schema = Avro::Schema->parse(q(["long","null"]));
> Avro::BinaryEncoder->encode(
> schema => $schema,
> data => undef,
> emit_cb => sub { $enc .= ${ $_[0] } },
> );
> {noformat}
> {noformat}
> Use of uninitialized value $data in pack at
> /home/johnkarp/git/avro/lang/perl/blib/lib/Avro/Schema.pm line 285.
> Use of uninitialized value $data in string eq at
> /home/johnkarp/git/avro/lang/perl/blib/lib/Avro/Schema.pm line 287.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-4004) [Rust] Canonical form transformation does not strip the logicalType
[
https://issues.apache.org/jira/browse/AVRO-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17859898#comment-17859898
]
Martin Tzvetanov Grigorov commented on AVRO-4004:
-
There might be a bug in the Python and Java impls but after making the change
in the Rust code I get a different fingerprint because of the namespace for
field "b".
>From the spec:
{code:java}
[FULLNAMES] Replace short names with fullnames, using applicable namespaces to
do so. Then eliminate namespace attributes, which are now redundant. {code}
{code:java}
running 1 test
Canonical form:
"{\"name\":\"test\",\"type\":\"record\",\"fields\":[{\"name\":\"a\",\"type\":\"long\"},{\"name\":\"test.a.b\",\"type\":\"string\"},{\"name\":\"c\",\"type\":{\"type\":\"long\"}}]}"
{code}
Note \"name\":\"{*}test.a.{*}b\"
PR: [https://github.com/apache/avro/pull/2976]
But I am not sure what to do with "test_equivalence_after_round_trip" unit
test. There is no way to reconstruct the schema after a round trip now ...
> [Rust] Canonical form transformation does not strip the logicalType
>
>
> Key: AVRO-4004
> URL: https://issues.apache.org/jira/browse/AVRO-4004
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Reporter: Dominik Mautz
>Priority: Major
>
> The Rust implementation of for the canonical transformation does not strip
> the _logicalType_ as required by the [STRIP] rule
> ([https://avro.apache.org/docs/1.11.0/spec.html#Transforming+into+Parsing+Canonical+Form]).
> This results in different fingerprints for the same schema compared to other
> implementations (at least for Python and Java)
> This is for instance can become an issue for the kafka-delta-ingest
> ([https://github.com/delta-io/kafka-delta-ingest]).
> Rust
> {code:java}
> [package]
> name = "avro issue"
> version = "0.2.0"
> edition = "2018"
> [dependencies]
> apache-avro = "0.16.0"
> anyhow = "1.0.86"
> {code}
> {code:java}
> use anyhow::Result;
> use apache_avro::{rabin::Rabin, Schema};
> use sha2::Sha256;
> fn main() -> Result<()> {
> let schema_str = r#"
> {
> "type": "record",
> "name": "test",
> "fields": [
> {"name": "a", "type": "long", "default": 42, "doc": "The field
> a"},
> {"name": "b", "type": "string", "namespace": "test.a"},
> {"name": "c", "type": "long", "logicalType": "timestamp-micros"}
> ]
> }"#;
> let schema = Schema::parse_str(schema_str)?;
> let canonical_form = schema.canonical_form();
> let fp_rabin = schema.fingerprint::();
> println!("Canonical form: {}", canonical_form);
> println!("Rabin fingerprint: {}", fp_rabin);
> Ok(())
> }
> {code}
> Output:
> {code:java}
> Canonical form:
> {"name":"test","type":"record","fields":[{"name":"a","type":"long"},{"name":"b","type":"string"},{"name":"c","type":{"type":"long","logicalType":"timestamp-micros"}}]}
> Rabin fingerprint: 28cf0a67d9937bb3
> {code}
> As you can see, the _logicalType_ is still present in the "canonical form."
> Python
> {code:python}
>
> import avro.schema
> schema_str = """
> {
> "type": "record",
> "name": "test",
> "fields": [
> {"name": "a", "type": "long", "default": 42, "doc": "The field
> a"},
> {"name": "b", "type": "string", "namespace": "test.a"},
> {"name": "c", "type": "long", "logicalType": "timestamp-micros"}
> ]
> }"""
> schema = avro.schema.parse(schema_str)
> print(f"Canonical form: {schema.canonical_form}")
> print(f"Rabin fingerprint: {schema.fingerprint().hex()}")
> {code}
> Output:
> {code:java}
> Canonical form:
> {"name":"test","type":"record","fields":[{"name":"a","type":"long"},{"name":"b","type":"string"},{"name":"c","type":"long"}]}
> Rabin fingerprint: 385501e341b00a1c
> {code}
> Java returns the same output as python.
> Imho, I think that changing the line
> [https://github.com/apache/avro/blob/main/lang/rust/avro/src/schema.rs#L2159]
> to
> {code:java}
> //...
> if field_ordering_position(k).is_none() || k == "default" || k == "doc" || k
> == "aliases" || k == "logicalType" {
> //...
> {code}
> should resolve the issue. However, I am unsure if this line should actually
> include more even attributes (other than the currently explicitly stated).
> Nevertheless, the test in
> [https://github.com/apache/avro/blob/fdab5db0816e28e3e10c87910c8b6f98c33072dc/lang/rust/avro/src/schema.rs#L3388]
> must also be adopted to reflect the correct transformation of the canonical
> form and the corresponding fingerprint.
> Rabin: 385501e341b00a1c
> MD5: 384f46367ef8c22dbbf44109b82ff7aa
> SHA-256: 8e72f58f2d84a59d6a08e8db5fdc6484dee35babf33179cea72889ae63083f36
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-1523) Perl API: int/long type minimum value checks are off by one
[ https://issues.apache.org/jira/browse/AVRO-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov updated AVRO-1523: Fix Version/s: 1.12.0 (was: 1.9.0) Assignee: José Joaquín Atria (was: John Karp) Resolution: Fixed Status: Resolved (was: Patch Available) > Perl API: int/long type minimum value checks are off by one > --- > > Key: AVRO-1523 > URL: https://issues.apache.org/jira/browse/AVRO-1523 > Project: Apache Avro > Issue Type: Bug > Components: perl >Reporter: John Karp >Assignee: José Joaquín Atria >Priority: Minor > Fix For: 1.12.0 > > Attachments: AVRO-1523.patch > > > -2,147,483,648 is rejected as an int, and −9,223,372,036,854,775,808 is > rejected as a long when passed to the binary encoder, but they are valid > signed 32-bit and 64-bit numbers respectively. > The problem is that the range check is made against the absolute value of the > input, but in two's complement arithmetic types the minimum and maximum > values have different absolute values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3992) [C++] Encoding a record with 0 fields in a vector throws
[
https://issues.apache.org/jira/browse/AVRO-3992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3992.
-
Fix Version/s: 1.12.0
Assignee: Gerrit Birkeland
Resolution: Fixed
> [C++] Encoding a record with 0 fields in a vector throws
>
>
> Key: AVRO-3992
> URL: https://issues.apache.org/jira/browse/AVRO-3992
> Project: Apache Avro
> Issue Type: Improvement
> Components: c++
>Affects Versions: 1.11.3
>Reporter: Gerrit Birkeland
>Assignee: Gerrit Birkeland
>Priority: Major
> Fix For: 1.12.0
>
>
> I have an Avro schema resembling the following:
> {code:java}
> {
> "type": "record",
> "name": "StackCalculator",
> "fields": [
> {
> "name": "stack",
> "type": {
> "type": "array",
> "items": [
> "int",
> {
> "type": "record",
> "name": "Dup",
> "fields": []
> },
> {
> "type": "record",
> "name": "Add",
> "fields": []
> }
> ]
> }
> }
> ]
> }
> {code}
> If I create one of these records with the stack:
> {code:java}
> uer::StackCalculator calc;
> uer::StackCalculator::stack_item_t item;
> item.set_int(3);
> calc.stack.push_back(item);
> item.set_Dup(uer::Dup());
> calc.stack.push_back(item);
> item.set_Add(uer::Add());
> calc.stack.push_back(item);
> {code}
> and try to encode this
> {code:java}
> ValidSchema s;
> ifstream ifs("jsonschemas/union_empty_record");
> compileJsonSchema(ifs, s);
> unique_ptr os = memoryOutputStream();
> EncoderPtr e = validatingEncoder(s, jsonPrettyEncoder());
> e->init(*os);
> avro::encode(*e, calc);
> {code}
> Avro throws {{{}startItem at not an item boundary{}}}. If the records without
> fields are given a dummy field, this works.
> Fix available at [https://github.com/apache/avro/pull/2927] - bot didn't pick
> it up since the PR was first
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-1830) Avro-Perl DataFileReader chokes when avro.codec is absent
[ https://issues.apache.org/jira/browse/AVRO-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov updated AVRO-1830: Fix Version/s: 1.12.0 Assignee: Martin Tzvetanov Grigorov Resolution: Fixed Status: Resolved (was: Patch Available) > Avro-Perl DataFileReader chokes when avro.codec is absent > - > > Key: AVRO-1830 > URL: https://issues.apache.org/jira/browse/AVRO-1830 > Project: Apache Avro > Issue Type: Bug > Components: perl >Affects Versions: 1.8.0 >Reporter: SK Liew >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.0 > > Attachments: Avro-1830.patch > > Time Spent: 40m > Remaining Estimate: 0h > > When a container does not specify its "avro.codec", it should be assumed to > be "null". An exception is thrown when I try to read such a container using > Avro::DataFileReader. The error happens at Avro/DataFileReader.pm line 101. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-4007) [Rust] Faster is_nullable for UnionSchema
[
https://issues.apache.org/jira/browse/AVRO-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-4007.
-
Fix Version/s: 1.12.0
1.11.4
Resolution: Fixed
> [Rust] Faster is_nullable for UnionSchema
> -
>
> Key: AVRO-4007
> URL: https://issues.apache.org/jira/browse/AVRO-4007
> Project: Apache Avro
> Issue Type: Improvement
> Components: rust
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> https://github.com/apache/avro/pull/2961
> {code}
> Writing large amounts of avro data in rust is slow because (in my case) ~40%
> of total run time is spent in the function UnionSchema::is_nullable. The
> issue is that the x == Schema::Null invokes schema canonicalization which is
> apparently somewhat slow. I've modified the method to use match instead and
> see a considerable performance improvement.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (AVRO-4007) [Rust] Faster is_nullable for UnionSchema
[
https://issues.apache.org/jira/browse/AVRO-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov reassigned AVRO-4007:
---
> [Rust] Faster is_nullable for UnionSchema
> -
>
> Key: AVRO-4007
> URL: https://issues.apache.org/jira/browse/AVRO-4007
> Project: Apache Avro
> Issue Type: Improvement
> Components: rust
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
>
> https://github.com/apache/avro/pull/2961
> {code}
> Writing large amounts of avro data in rust is slow because (in my case) ~40%
> of total run time is spent in the function UnionSchema::is_nullable. The
> issue is that the x == Schema::Null invokes schema canonicalization which is
> apparently somewhat slow. I've modified the method to use match instead and
> see a considerable performance improvement.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-1514) Clean up perl API dependencies
[ https://issues.apache.org/jira/browse/AVRO-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov updated AVRO-1514: Fix Version/s: 1.12.0 Assignee: Martin Tzvetanov Grigorov (was: John Karp) Resolution: Fixed Status: Resolved (was: Patch Available) > Clean up perl API dependencies > -- > > Key: AVRO-1514 > URL: https://issues.apache.org/jira/browse/AVRO-1514 > Project: Apache Avro > Issue Type: Improvement > Components: perl >Reporter: John Karp >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.0 > > Attachments: AVRO-1514-0.patch > > Time Spent: 10m > Remaining Estimate: 0h > > If we assume a non-ancient perl (>=5.8.1), we can clean up the dependencies: > (build) Module::Install: bundle it > (build) Module::Install::ReadmeFromPod: keep > (build) Module::Install::Repository: remove, hardcode repository value > instead of autodetecting > (build) Test::More 0.88: keep, but note requisite version built in starting > at 5.10.1 > (test) Test::Exception: keep > (test) Test::Pod: declare (missing in Makefile.PL) > (test/run) Math::BigInt: don't declare, now built-in > (run) JSON::XS: replace with JSON to not tie to a backend > (run) parent: keep, but note built-in starting at 5.10.1 > (run) Compress::Zlib: keep, but note built-in starting at 5.9.3 > (run) IO::String: replace with perl 5.8 functionality > (run) Encode: don't declare, now built-in > (run) Regexp::Common: keep > (run) Object::Tiny: keep > (run) Try::Tiny: keep -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-4005) [Rust] JSON Encoding is not supported
[ https://issues.apache.org/jira/browse/AVRO-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17859599#comment-17859599 ] Martin Tzvetanov Grigorov commented on AVRO-4005: - PRs are welcome! Without more details in the Jira description this issue is not actionable! > [Rust] JSON Encoding is not supported > - > > Key: AVRO-4005 > URL: https://issues.apache.org/jira/browse/AVRO-4005 > Project: Apache Avro > Issue Type: New Feature > Components: rust >Reporter: xxchan >Priority: Major > > In the rust lib, there's no way to read/write with JSON encoding > [https://avro.apache.org/docs/1.11.1/specification/#json-encoding] > > There's an implementation of From/To serde_json::Value, but it's not relevant > (and the implementation itself is dubious) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AVRO-4005) [Rust] JSON Encoding is not supported
[ https://issues.apache.org/jira/browse/AVRO-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov updated AVRO-4005: Priority: Minor (was: Major) > [Rust] JSON Encoding is not supported > - > > Key: AVRO-4005 > URL: https://issues.apache.org/jira/browse/AVRO-4005 > Project: Apache Avro > Issue Type: New Feature > Components: rust >Reporter: xxchan >Priority: Minor > > In the rust lib, there's no way to read/write with JSON encoding > [https://avro.apache.org/docs/1.11.1/specification/#json-encoding] > > There's an implementation of From/To serde_json::Value, but it's not relevant > (and the implementation itself is dubious) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-4002) download page avro still show 1.11.1 and not latest 1.11.3
[ https://issues.apache.org/jira/browse/AVRO-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856494#comment-17856494 ] Martin Tzvetanov Grigorov commented on AVRO-4002: - This is a duplicate but I cannot find the other ticket (oh, Jira) > download page avro still show 1.11.1 and not latest 1.11.3 > -- > > Key: AVRO-4002 > URL: https://issues.apache.org/jira/browse/AVRO-4002 > Project: Apache Avro > Issue Type: Bug >Reporter: raphaelauv >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-4001) [Rust] Is there plan for new release for apache-avro
[ https://issues.apache.org/jira/browse/AVRO-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856132#comment-17856132 ] Martin Tzvetanov Grigorov commented on AVRO-4001: - Rust Avro 0.17 will be released with Avro 1.12.0. There is a email discussion at dev@ mailing list - https://lists.apache.org/thread/6vbd3w5qk7mpb5lyrfyf2s0z1cymjt5w I cannot give you an exact date but it should be soon! > [Rust] Is there plan for new release for apache-avro > > > Key: AVRO-4001 > URL: https://issues.apache.org/jira/browse/AVRO-4001 > Project: Apache Avro > Issue Type: Wish >Reporter: zejiong dong >Priority: Major > > I find that the last release was gone 9 months ago. There are lots of fix > upon now. Is there a plan for a new release so that the dependent crate can > leverage this? E.g. > https://github.com/apache/iceberg-rust/issues/131#issuecomment-2169153738 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-4001) [Rust] Is there plan for new release for apache-avro
[ https://issues.apache.org/jira/browse/AVRO-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-4001. - Resolution: Not A Problem > [Rust] Is there plan for new release for apache-avro > > > Key: AVRO-4001 > URL: https://issues.apache.org/jira/browse/AVRO-4001 > Project: Apache Avro > Issue Type: Wish >Reporter: zejiong dong >Priority: Major > > I find that the last release was gone 9 months ago. There are lots of fix > upon now. Is there a plan for a new release so that the dependent crate can > leverage this? E.g. > https://github.com/apache/iceberg-rust/issues/131#issuecomment-2169153738 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3732) Code drop existing sources, updating headers, RAT, NOTICES, etc.
[ https://issues.apache.org/jira/browse/AVRO-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855600#comment-17855600 ] Martin Tzvetanov Grigorov commented on AVRO-3732: - [~olaservo] I've attached [^ReplaceLicense.java] I hope it is useful for you. > Code drop existing sources, updating headers, RAT, NOTICES, etc. > > > Key: AVRO-3732 > URL: https://issues.apache.org/jira/browse/AVRO-3732 > Project: Apache Avro > Issue Type: Sub-task >Reporter: Ryan Skraba >Assignee: Ola Hungerford >Priority: Major > Labels: pull-request-available > Attachments: ReplaceLicense.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Move the source to https://github.com/apache/avro/tree/master/lang/java in a > directory called gradle-plugin (parallel to maven-plugin). > To decide -- should we do a code dump to the destination or attempt to > maintain the history from the original repo? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AVRO-3732) Code drop existing sources, updating headers, RAT, NOTICES, etc.
[ https://issues.apache.org/jira/browse/AVRO-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov updated AVRO-3732: Attachment: ReplaceLicense.java > Code drop existing sources, updating headers, RAT, NOTICES, etc. > > > Key: AVRO-3732 > URL: https://issues.apache.org/jira/browse/AVRO-3732 > Project: Apache Avro > Issue Type: Sub-task >Reporter: Ryan Skraba >Assignee: Ola Hungerford >Priority: Major > Labels: pull-request-available > Attachments: ReplaceLicense.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Move the source to https://github.com/apache/avro/tree/master/lang/java in a > directory called gradle-plugin (parallel to maven-plugin). > To decide -- should we do a code dump to the destination or attempt to > maintain the history from the original repo? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (AVRO-3734) Integrate build with Apache Avro github actions / local build
[ https://issues.apache.org/jira/browse/AVRO-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855595#comment-17855595 ] Martin Tzvetanov Grigorov edited comment on AVRO-3734 at 6/17/24 11:57 AM: --- This task is about adding/extending CI jobs to make sure the new gradle-plugin builds fine. More or less it has been done with https://github.com/apache/avro/pull/2946. One thing I am not very happy about it is the number of the CI jobs - 130 ! Currently (without the gradle module) the number is just 8 (e.g. https://github.com/apache/avro/pull/2958) was (Author: mgrigorov): This task is about adding/extending CI jobs to make sure the new gradle-plugin builds fine. More or less it has been done with https://github.com/apache/avro/pull/2946. One thing I am not very happy about it the number of the CI jobs - 130 ! Currently (without the gradle module) the number is just 8 (e.g. https://github.com/apache/avro/pull/2958) > Integrate build with Apache Avro github actions / local build > - > > Key: AVRO-3734 > URL: https://issues.apache.org/jira/browse/AVRO-3734 > Project: Apache Avro > Issue Type: Sub-task >Reporter: Ryan Skraba >Assignee: Ola Hungerford >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3734) Integrate build with Apache Avro github actions / local build
[ https://issues.apache.org/jira/browse/AVRO-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855595#comment-17855595 ] Martin Tzvetanov Grigorov commented on AVRO-3734: - This task is about adding/extending CI jobs to make sure the new gradle-plugin builds fine. More or less it has been done with https://github.com/apache/avro/pull/2946. One thing I am not very happy about it the number of the CI jobs - 130 ! Currently (without the gradle module) the number is just 8 (e.g. https://github.com/apache/avro/pull/2958) > Integrate build with Apache Avro github actions / local build > - > > Key: AVRO-3734 > URL: https://issues.apache.org/jira/browse/AVRO-3734 > Project: Apache Avro > Issue Type: Sub-task >Reporter: Ryan Skraba >Assignee: Ola Hungerford >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3990) [C++] avrogencpp generates invalid code for union with a reserved word
[
https://issues.apache.org/jira/browse/AVRO-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3990.
-
Fix Version/s: 1.12.0
Assignee: Gerrit Birkeland
Resolution: Fixed
> [C++] avrogencpp generates invalid code for union with a reserved word
> --
>
> Key: AVRO-3990
> URL: https://issues.apache.org/jira/browse/AVRO-3990
> Project: Apache Avro
> Issue Type: Bug
>Reporter: Gerrit Birkeland
>Assignee: Gerrit Birkeland
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When avrogencpp is run with this schema, it generates C++ code with compiler
> errors due to inconsistently passing names through the {{decorate}} wrapper.
> {code:java}
> {
> "type": "record",
> "name": "Record",
> "fields": [
> {
> "name": "void",
> "type": [
> "int",
> "double"
> ]
> }
> ]
> }
> {code}
> This generates the following, note that the typedef uses {{void_t}} (one
> underscore) while references to the typedef use {{void__t}} (two underscores)
> {code:java}
> struct Record {
> typedef _cpp_reserved_words_union_typedef_Union__0__ void_t;
> void__t void_;
> Record() :
> void_(void__t())
> { }
> };
> {code}
> Note: This problem was injected after the latest release, so can only be
> reproduced with a build off of the current repo.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-3993) Writing an AVRO enum field with an invalid value generates unhelpful NPE
[
https://issues.apache.org/jira/browse/AVRO-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854939#comment-17854939
]
Martin Tzvetanov Grigorov commented on AVRO-3993:
-
It should have come from your Git settings:
What does `git config user.email` give you ?
> Writing an AVRO enum field with an invalid value generates unhelpful NPE
>
>
> Key: AVRO-3993
> URL: https://issues.apache.org/jira/browse/AVRO-3993
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Reporter: Gray
>Priority: Minor
> Labels: pull-request-available
> Attachments: avro-stacktrace.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{When an enum field is written with a symbol that is not one of the valid
> enum symbols configured in the schema, the code generates a NPE which turns
> into a null value message which is not extremely helpful. It would be useful
> if the message mentioned the invalid symbol and the available symbols from
> the schema.}}
> Here's a sample of the generated stack trace. More in the attachment:
> {{java.lang.NullPointerException: null value for (non-nullable) enum1 at
> record1.field1}}
> {{ ...}}
> {{Caused by: java.lang.NullPointerException}}
> {{ at org.apache.avro.Schema$EnumSchema.getEnumOrdinal(Schema.java:1118)}}
> {{...}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3995) [C++] Update build system to disallow compiling with unsupported language versions
[ https://issues.apache.org/jira/browse/AVRO-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3995. - Fix Version/s: 1.12.0 Assignee: Gerrit Birkeland Resolution: Fixed > [C++] Update build system to disallow compiling with unsupported language > versions > -- > > Key: AVRO-3995 > URL: https://issues.apache.org/jira/browse/AVRO-3995 > Project: Apache Avro > Issue Type: Improvement > Components: c++ >Affects Versions: 1.11.3 >Reporter: Gerrit Birkeland >Assignee: Gerrit Birkeland >Priority: Major > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > In August of 2023 a commit was merged to Avro which effectively forced all > users of the project to compile with C\+\+17 at a minimum, but this wasn't > enforced by the build system anywhere, so currently attempting to compile > Avro with a C\+\+11 or C\+\+14 compiler will result in build errors rather > than an obvious message telling the user what is wrong. > Avro should provide a user friendly error message when attempting to compile > the library with an unsupported C++ standard. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3852) Support Java 21
[ https://issues.apache.org/jira/browse/AVRO-3852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3852. - Resolution: Fixed > Support Java 21 > --- > > Key: AVRO-3852 > URL: https://issues.apache.org/jira/browse/AVRO-3852 > Project: Apache Avro > Issue Type: Improvement > Components: build, java >Affects Versions: 1.12.0 >Reporter: Ismaël Mejía >Assignee: Ismaël Mejía >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > We should support most LTS versions so we should move the current validation > CI jobs to test against Java 21 and do the required fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-2848) Snappy-java1.1.7.5 has error log in mvn-site
[
https://issues.apache.org/jira/browse/AVRO-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-2848.
-
Resolution: Information Provided
> Snappy-java1.1.7.5 has error log in mvn-site
>
>
> Key: AVRO-2848
> URL: https://issues.apache.org/jira/browse/AVRO-2848
> Project: Apache Avro
> Issue Type: Bug
> Components: build, java
>Reporter: Zezeng Wang
>Priority: Minor
>
> When I use the mvn site test in lang / java, the snappy-java error log
> appears, but the mvn site result is successful, which confuses me.
> I am not sure if this is avro bypass check, or a problem with snappy-java, or
> a problem with maven, I just want to make a record, maybe someone familiar
> with this can know the problem immediately without spending extra time.
> error log：
> {code:java}
> [DEBUG] Extension realms for project
> org.xerial.snappy:snappy-java:bundle:1.1.7.5: (none)
> [DEBUG] Looking up Lifecyle mappings for packaging bundle from
> ClassRealm[plexus.core, parent: null]
> [WARNING] Unable to create Maven project for
> org.xerial.snappy:snappy-java:jar:1.1.7.5 from repository.
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] Unknown packaging: bundle @ 6, column 16
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:195)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:368)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:253)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-2715) Building with Visual Studio and Snappy enabled fails
[
https://issues.apache.org/jira/browse/AVRO-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-2715.
-
Fix Version/s: 1.11.0
Assignee: Daniel Kulp
Resolution: Fixed
> Building with Visual Studio and Snappy enabled fails
>
>
> Key: AVRO-2715
> URL: https://issues.apache.org/jira/browse/AVRO-2715
> Project: Apache Avro
> Issue Type: Bug
> Environment: * Windows 10
> * Microsoft Visual Studio 2019
> * CMake 3.15
> * Target architecture: x64
>Reporter: Michael Spector
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 1.11.0
>
>
> I'm getting the following error:
> {code:java}
> ...\Projects\avro\lang\c++\impl\DataFile.cc(32,10): fatal error C1083: Cannot
> open include file: 'snappy.h': No such file or directory
> [C:\Users\mispecto\Projects\avro\lang\c++\build\avrocpp.vcxproj]
> ...\Projects\avro\lang\c++\impl\DataFile.cc(32,10): fatal error C1083: Cannot
> open include file: 'snappy.h': No such file or directory
> [C:\Users\mispecto\Projects\avro\lang\c++\build\avrocpp_s.vcxproj]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-1830) Avro-Perl DataFileReader chokes when avro.codec is absent
[ https://issues.apache.org/jira/browse/AVRO-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854669#comment-17854669 ] Martin Tzvetanov Grigorov commented on AVRO-1830: - [~jjatria] Please send a PR with the suggested/updated patch! Thanks! > Avro-Perl DataFileReader chokes when avro.codec is absent > - > > Key: AVRO-1830 > URL: https://issues.apache.org/jira/browse/AVRO-1830 > Project: Apache Avro > Issue Type: Bug > Components: perl >Affects Versions: 1.8.0 >Reporter: SK Liew >Priority: Minor > Attachments: Avro-1830.patch > > > When a container does not specify its "avro.codec", it should be assumed to > be "null". An exception is thrown when I try to read such a container using > Avro::DataFileReader. The error happens at Avro/DataFileReader.pm line 101. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-2434) Make the supported Perl version consistent
[
https://issues.apache.org/jira/browse/AVRO-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854668#comment-17854668
]
Martin Tzvetanov Grigorov commented on AVRO-2434:
-
I see no problem with moving to 5.24 for Avro 1.12.0.
The other Avro SDKs also update their language versions for 1.12.0, e.g. the
Java SDK moves from Java 8 to Java 11 (or maybe 17), the C++ SDK now requires
C++17 or newer, the Rust SDK requires ~latest-5 (1.78.0 => 1.73.0).
> Make the supported Perl version consistent
> --
>
> Key: AVRO-2434
> URL: https://issues.apache.org/jira/browse/AVRO-2434
> Project: Apache Avro
> Issue Type: Improvement
> Components: perl
>Reporter: Kengo Seki
>Priority: Major
>
> According to BUILD.md, the supported Perl version seems to be 5.24.1+, while
> Avro.pm says 5.8.1+.
> {code:title=BUILD.md}
> The following packages must be installed before Avro can be built:
> (snip)
> - Perl: Perl 5.24.1 or greater, gmake, Module::Install,
> {code}
> {code:title=lang/perl/lib/Avro.pm}
> use 5.008_001;
> {code}
> Which version is the right one? If the former is, we should simply update
> Avro.pm too.
> If the latter is, we should update BUILD.md and Dockerfile to use Perl 5.8.1
> for building and testing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-1514) Clean up perl API dependencies
[ https://issues.apache.org/jira/browse/AVRO-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854662#comment-17854662 ] Martin Tzvetanov Grigorov commented on AVRO-1514: - [~jjatria] Do you want to apply any of the other changes in the attached patch ? (via PR) > Clean up perl API dependencies > -- > > Key: AVRO-1514 > URL: https://issues.apache.org/jira/browse/AVRO-1514 > Project: Apache Avro > Issue Type: Improvement > Components: perl >Reporter: John Karp >Assignee: John Karp >Priority: Minor > Attachments: AVRO-1514-0.patch > > > If we assume a non-ancient perl (>=5.8.1), we can clean up the dependencies: > (build) Module::Install: bundle it > (build) Module::Install::ReadmeFromPod: keep > (build) Module::Install::Repository: remove, hardcode repository value > instead of autodetecting > (build) Test::More 0.88: keep, but note requisite version built in starting > at 5.10.1 > (test) Test::Exception: keep > (test) Test::Pod: declare (missing in Makefile.PL) > (test/run) Math::BigInt: don't declare, now built-in > (run) JSON::XS: replace with JSON to not tie to a backend > (run) parent: keep, but note built-in starting at 5.10.1 > (run) Compress::Zlib: keep, but note built-in starting at 5.9.3 > (run) IO::String: replace with perl 5.8 functionality > (run) Encode: don't declare, now built-in > (run) Regexp::Common: keep > (run) Object::Tiny: keep > (run) Try::Tiny: keep -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3998) Switch Perl library from JSON::XS to JSON::MaybeXS
[ https://issues.apache.org/jira/browse/AVRO-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3998. - Fix Version/s: 1.12.0 Assignee: Fokko Driesprong Resolution: Fixed > Switch Perl library from JSON::XS to JSON::MaybeXS > -- > > Key: AVRO-3998 > URL: https://issues.apache.org/jira/browse/AVRO-3998 > Project: Apache Avro > Issue Type: Improvement > Components: perl >Reporter: José Joaquín Atria >Assignee: Fokko Driesprong >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The Perl library currently depends directly on JSON::XS, which forces a > decision of the JSON backend on the user. Perl currently has a number of > compatible backends, including JSON::PP, which is shipped with Perl itself. > The JSON::MaybeXS library serves as a compatibility layer to allow users to > select the JSON backend that matches their stack, rather than forcing them to > install a specific one, while still benefiting from the performance boost of > XS libraries if they are available. > Note that AVRO-1514 already exists aiming to clean up some dependencies, > including replacing JSON::XS with plain JSON, a different compatibility layer. > While the other changes in AVRO-1514 I think are desirable, that ticket seems > to have stalled, and JSON::MaybeXS seems like a better alternative since it > also supports Cpanel::JSON::XS as an additional possible backend. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3999) Avoid warnings in Perl test suite
[
https://issues.apache.org/jira/browse/AVRO-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3999.
-
Fix Version/s: 1.12.0
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
> Avoid warnings in Perl test suite
> -
>
> Key: AVRO-3999
> URL: https://issues.apache.org/jira/browse/AVRO-3999
> Project: Apache Avro
> Issue Type: Improvement
> Components: perl
>Reporter: José Joaquín Atria
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The test suite generated several warnings which could easily be avoided.
> Specifically an undefined value being stringified in t/03_bin_decode.t, and
> exiting a subroutine via next in xt/schema.t. See output below for
> illustration:
>
> {code:java}
> $ ./build.sh test
> include /home/user/avro/lang/perl/inc/Module/Install.pm
> include inc/Module/Install/Metadata.pm
> include inc/Module/Install/Base.pm
> include inc/Module/Install/ReadmeFromPod.pm
> readme_from lib/Avro.pm to txt
> include inc/Module/Install/Repository.pm
> Cannot determine repository URL
> include inc/Module/Install/MakeMaker.pm
> include inc/Module/Install/Makefile.pm
> Generating a Unix-style Makefile
> Writing Makefile for Avro
> Writing MYMETA.yml and MYMETA.json
> Writing META.yml
> sed -e s/++MODULE_VERSION++/1.12.0-SNAPSHOT/ >blib/lib/Avro/BinaryEncoder.pm
> sed -e s/++MODULE_VERSION++/1.12.0-SNAPSHOT/ >blib/lib/Avro/DataFileWriter.pm
> sed -e s/++MODULE_VERSION++/1.12.0-SNAPSHOT/ >blib/lib/Avro/BinaryDecoder.pm
> sed -e s/++MODULE_VERSION++/1.12.0-SNAPSHOT/ >blib/lib/Avro/DataFileReader.pm
> sed -e s/++MODULE_VERSION++/1.12.0-SNAPSHOT/ >blib/lib/Avro/DataFile.pm
> sed -e s/++MODULE_VERSION++/1.12.0-SNAPSHOT/ >blib/lib/Avro/Schema.pm
> sed -e s/++MODULE_VERSION++/1.12.0-SNAPSHOT/ >blib/lib/Avro/Protocol/Message.pm
> sed -e s/++MODULE_VERSION++/1.12.0-SNAPSHOT/ >blib/lib/Avro/Protocol.pm
> sed -e s/++MODULE_VERSION++/1.12.0-SNAPSHOT/ blib/lib/Avro.pm
> PERL_DL_NONLAZY=1 "/home/user/.perl/perls/perl-5.36.0/bin/perl"
> "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef
> *Test::Harness::Switches; test_harness(0, 'inc', 'blib/lib', 'blib/arch')"
> t/*.t xt/*.t
> t/00_compile.t . ok
> t/01_names.t ... ok
> t/01_schema.t .. ok
> t/02_bin_encode.t .. ok
> t/03_bin_decode.t .. 1/? Use of uninitialized value in concatenation (.) or
> string at /home/user/.perl/perls/perl-5.36.0/lib/site_perl/5.36.0/Error.pm
> line 288.
> t/03_bin_decode.t .. ok
> t/04_datafile.t ok
> t/05_protocol.t ok
> xt/interop.t ... ok
> xt/pod.t ... ok
> xt/schema.t 1/? Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at xt/schema.t line 26.
> Exiting subroutine via next at
[jira] [Resolved] (AVRO-3994) [C++] Solidus (/) should not be escaped in JSON output
[
https://issues.apache.org/jira/browse/AVRO-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3994.
-
Fix Version/s: 1.12.0
Assignee: Gerrit Birkeland
Resolution: Fixed
> [C++] Solidus (/) should not be escaped in JSON output
> --
>
> Key: AVRO-3994
> URL: https://issues.apache.org/jira/browse/AVRO-3994
> Project: Apache Avro
> Issue Type: Improvement
> Components: c++
>Affects Versions: 1.11.0, 1.10.1, 1.10.2, 1.11.1, 1.11.2, 1.11.3
>Reporter: Gerrit Birkeland
>Assignee: Gerrit Birkeland
>Priority: Major
> Fix For: 1.12.0
>
>
> The JSON standard permits a solidus ({{{}/{}}}) to be escaped in strings, but
> does not require that it be escaped. Most JSON serializers used by other
> packages/languages do not escape solidus characters, so for consistency it
> would be nice if Avro also did not perform this useless escape.
> Fixed with https://github.com/apache/avro/pull/2929
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (AVRO-3734) Integrate build with Apache Avro github actions / local build
[ https://issues.apache.org/jira/browse/AVRO-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov reassigned AVRO-3734: --- Assignee: Ola Hungerford > Integrate build with Apache Avro github actions / local build > - > > Key: AVRO-3734 > URL: https://issues.apache.org/jira/browse/AVRO-3734 > Project: Apache Avro > Issue Type: Sub-task >Reporter: Ryan Skraba >Assignee: Ola Hungerford >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AVRO-3733) Migrate package names and artifacts to org.apache.avro namespace
[ https://issues.apache.org/jira/browse/AVRO-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov reassigned AVRO-3733: --- Assignee: Ola Hungerford > Migrate package names and artifacts to org.apache.avro namespace > > > Key: AVRO-3733 > URL: https://issues.apache.org/jira/browse/AVRO-3733 > Project: Apache Avro > Issue Type: Sub-task >Reporter: Ryan Skraba >Assignee: Ola Hungerford >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3732) Code drop existing sources, updating headers, RAT, NOTICES, etc.
[ https://issues.apache.org/jira/browse/AVRO-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847797#comment-17847797 ] Martin Tzvetanov Grigorov commented on AVRO-3732: - [~olaservo] I've assigned the ticket to you! Feel free to start new discussion(s) at d...@avro.apache.org or join ASK Slack #avro channel. > Code drop existing sources, updating headers, RAT, NOTICES, etc. > > > Key: AVRO-3732 > URL: https://issues.apache.org/jira/browse/AVRO-3732 > Project: Apache Avro > Issue Type: Sub-task >Reporter: Ryan Skraba >Assignee: Ola Hungerford >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > Move the source to https://github.com/apache/avro/tree/master/lang/java in a > directory called gradle-plugin (parallel to maven-plugin). > To decide -- should we do a code dump to the destination or attempt to > maintain the history from the original repo? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AVRO-3732) Code drop existing sources, updating headers, RAT, NOTICES, etc.
[ https://issues.apache.org/jira/browse/AVRO-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov reassigned AVRO-3732: --- Assignee: Ola Hungerford (was: Samael Bate) > Code drop existing sources, updating headers, RAT, NOTICES, etc. > > > Key: AVRO-3732 > URL: https://issues.apache.org/jira/browse/AVRO-3732 > Project: Apache Avro > Issue Type: Sub-task >Reporter: Ryan Skraba >Assignee: Ola Hungerford >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > Move the source to https://github.com/apache/avro/tree/master/lang/java in a > directory called gradle-plugin (parallel to maven-plugin). > To decide -- should we do a code dump to the destination or attempt to > maintain the history from the original repo? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AVRO-3965) Default values for fixed can be longer than size
[ https://issues.apache.org/jira/browse/AVRO-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov updated AVRO-3965: Component/s: rust > Default values for fixed can be longer than size > > > Key: AVRO-3965 > URL: https://issues.apache.org/jira/browse/AVRO-3965 > Project: Apache Avro > Issue Type: Bug > Components: java, rust >Reporter: Roman Mitasov >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > A value longer than the specified size can be put into "default" property of > a "fixed" field. > Behaviour in this case is not documented. > This should either be forbidden or documented. Even adding a UB warning in > the documentation would be better than the current situation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AVRO-3968) Support for custom @AvroNamespace annotation
[ https://issues.apache.org/jira/browse/AVRO-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov reassigned AVRO-3968: --- Assignee: Henry Fernandes > Support for custom @AvroNamespace annotation > - > > Key: AVRO-3968 > URL: https://issues.apache.org/jira/browse/AVRO-3968 > Project: Apache Avro > Issue Type: Wish >Reporter: Henry Fernandes >Assignee: Henry Fernandes >Priority: Major > > Currently there are several java annotations like @AvroSchema, @AvroName, > @AvroDoc etc that can be used to decorate Java POJO classes which in turn are > used when generating avro schema with reflection. > While @AvroName annotation comes handy for overriding the name of fields, > there is no support for overriding the namespace. > > Currently by default the java POJO's package name is used as the namespace. > This is a bit restrictive as there can be cases where we may want to generate > the schema with a different namespace. > > The ask over here is to provide a @AvroNamespace annotation that can let us > override the namespace to what we intend to. > > Happy to contribute with a PR for the same. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3967) Replace boost::format with fmt
[ https://issues.apache.org/jira/browse/AVRO-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3967. - Fix Version/s: 1.12.0 Resolution: Fixed > Replace boost::format with fmt > -- > > Key: AVRO-3967 > URL: https://issues.apache.org/jira/browse/AVRO-3967 > Project: Apache Avro > Issue Type: Task > Components: c++ >Reporter: Mikhail Koviazin >Assignee: Mikhail Koviazin >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > fmt ([https://fmt.dev)|https://fmt.dev)/] is a modern C++ library. It got so > much popularity that in C++20 it became std::format. > Replacing boost::format with it should significantly improve the readability, > performance and the binary size. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3732) Code drop existing sources, updating headers, RAT, NOTICES, etc.
[ https://issues.apache.org/jira/browse/AVRO-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836603#comment-17836603 ] Martin Tzvetanov Grigorov commented on AVRO-3732: - Hi! Thanks for offering your help with this ! You could: - start the integration from scratch - clone https://github.com/SingingBush/avro/tree/migration/import_gradle_plugin and fix any issues until the CI jobs are green again and the Gradle plugin works as it should > Code drop existing sources, updating headers, RAT, NOTICES, etc. > > > Key: AVRO-3732 > URL: https://issues.apache.org/jira/browse/AVRO-3732 > Project: Apache Avro > Issue Type: Sub-task >Reporter: Ryan Skraba >Assignee: Samael Bate >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Move the source to https://github.com/apache/avro/tree/master/lang/java in a > directory called gradle-plugin (parallel to maven-plugin). > To decide -- should we do a code dump to the destination or attempt to > maintain the history from the original repo? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3974) [Rust] incorrect compatibility checks with ref fields
[
https://issues.apache.org/jira/browse/AVRO-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3974.
-
Fix Version/s: 1.12.0
1.11.4
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
> [Rust] incorrect compatibility checks with ref fields
> -
>
> Key: AVRO-3974
> URL: https://issues.apache.org/jira/browse/AVRO-3974
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Reporter: mknaw
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A schema with a field that is a ref to a different schema is incompatible
> with itself, per `SchemaCompatibility`:
> {code:java}
> use apache_avro::{schema_compatibility::SchemaCompatibility, Schema};
> fn main() {
> let schema_strs = vec![
> r#"{
> "type": "record",
> "name": "Child",
> "namespace": "avro",
> "fields": [
> {
> "name": "val",
> "type": "int"
> }
> ]
> }
> "#,
> r#"{
> "type": "record",
> "name": "Parent",
> "namespace": "avro",
> "fields": [
> {
> "name": "child",
> "type": "avro.Child"
> }
> ]
> }
> "#,
> ];
>
> let schemas = Schema::parse_list(_strs).unwrap();
> if let Err(e) = SchemaCompatibility::can_read(
> [1],
> [1]
> ) {
> eprintln!("{}", e);
> }
> } {code}
>
> Here it is somewhat ambiguous to me how the fix should look. of course the
> simplest (and already an improvement over the current state) is just to
> verify the names are the same, and maybe it's assumed callers doing compat
> checks across a batch will check the compat of the referenced schema
> separately from the referencing schema. But this isn't quite satisfactory -
> imagine having a complex field that was previously defined inline, but now
> want to reuse it across multiple schemas. In this case, it does not seem like
> replacing the inline definition with a ref should be incompatible. So, it
> seems that some sort of "recursive flattening" of the schema prior to compat
> check would be the ideal fix. Or, maybe, the compat check just checks on
> names, but callers who want this behavior can do some (new?) "flattening"
> operation on some schema among `ResolvedSchema`, and then use that as the
> argument for compat checks.
> This appears to be the case both on `main` at the time of writing
> (`00afbaed`) and `0.16.0`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-3974) [Rust] incorrect compatibility checks with ref fields
[
https://issues.apache.org/jira/browse/AVRO-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836058#comment-17836058
]
Martin Tzvetanov Grigorov commented on AVRO-3974:
-
[~mknaw] Please review https://github.com/apache/avro/pull/2847
> [Rust] incorrect compatibility checks with ref fields
> -
>
> Key: AVRO-3974
> URL: https://issues.apache.org/jira/browse/AVRO-3974
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Reporter: mknaw
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A schema with a field that is a ref to a different schema is incompatible
> with itself, per `SchemaCompatibility`:
> {code:java}
> use apache_avro::{schema_compatibility::SchemaCompatibility, Schema};
> fn main() {
> let schema_strs = vec![
> r#"{
> "type": "record",
> "name": "Child",
> "namespace": "avro",
> "fields": [
> {
> "name": "val",
> "type": "int"
> }
> ]
> }
> "#,
> r#"{
> "type": "record",
> "name": "Parent",
> "namespace": "avro",
> "fields": [
> {
> "name": "child",
> "type": "avro.Child"
> }
> ]
> }
> "#,
> ];
>
> let schemas = Schema::parse_list(_strs).unwrap();
> if let Err(e) = SchemaCompatibility::can_read(
> [1],
> [1]
> ) {
> eprintln!("{}", e);
> }
> } {code}
>
> Here it is somewhat ambiguous to me how the fix should look. of course the
> simplest (and already an improvement over the current state) is just to
> verify the names are the same, and maybe it's assumed callers doing compat
> checks across a batch will check the compat of the referenced schema
> separately from the referencing schema. But this isn't quite satisfactory -
> imagine having a complex field that was previously defined inline, but now
> want to reuse it across multiple schemas. In this case, it does not seem like
> replacing the inline definition with a ref should be incompatible. So, it
> seems that some sort of "recursive flattening" of the schema prior to compat
> check would be the ideal fix. Or, maybe, the compat check just checks on
> names, but callers who want this behavior can do some (new?) "flattening"
> operation on some schema among `ResolvedSchema`, and then use that as the
> argument for compat checks.
> This appears to be the case both on `main` at the time of writing
> (`00afbaed`) and `0.16.0`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3970) [Rust] incorrect compatibility checks with logicalType uuid
[
https://issues.apache.org/jira/browse/AVRO-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3970.
-
Fix Version/s: 1.12.0
1.11.4
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
> [Rust] incorrect compatibility checks with logicalType uuid
> ---
>
> Key: AVRO-3970
> URL: https://issues.apache.org/jira/browse/AVRO-3970
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Reporter: mknaw
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A schema with a logicalType uuid field is incompatible with itself, per
> `SchemaCompatibility`:
>
> {code:java}
> use apache_avro::{Schema, schema_compatibility::SchemaCompatibility};
> fn main() {
> let schema_str = r#"\{"type": "string", "logicalType": "uuid"}"#;
> let writers_schema = Schema::parse_str(schema_str).unwrap();
> let readers_schema = Schema::parse_str(schema_str).unwrap();
> if let Err(err) = SchemaCompatibility::can_read(_schema,
> _schema) {
> eprintln!("Error: {}", err);
> }
> }
> {code}
>
> this is the behavior on `main` as of writing (`876eae32`) and on the latest
> version on crates.rs (`v0.16.0`)
> I have a proposed fix here:
> [https://github.com/apache/avro/compare/main...mknaw:avro:logical-type-compat-fix]
> Perhaps there are other valid logicalTypes with this behavior. I have not
> checked every logicalType yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-3970) [Rust] incorrect compatibility checks with logicalType uuid
[
https://issues.apache.org/jira/browse/AVRO-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834188#comment-17834188
]
Martin Tzvetanov Grigorov commented on AVRO-3970:
-
Please send a Pull Request with your changes!
If there are more missing logical types then they could be improved in more PRs!
Thank you!
> [Rust] incorrect compatibility checks with logicalType uuid
> ---
>
> Key: AVRO-3970
> URL: https://issues.apache.org/jira/browse/AVRO-3970
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Reporter: mknaw
>Priority: Minor
>
> A schema with a logicalType uuid field is incompatible with itself, per
> `SchemaCompatibility`:
>
> {code:java}
> use apache_avro::{Schema, schema_compatibility::SchemaCompatibility};
> fn main() {
> let schema_str = r#"\{"type": "string", "logicalType": "uuid"}"#;
> let writers_schema = Schema::parse_str(schema_str).unwrap();
> let readers_schema = Schema::parse_str(schema_str).unwrap();
> if let Err(err) = SchemaCompatibility::can_read(_schema,
> _schema) {
> eprintln!("Error: {}", err);
> }
> }
> {code}
>
> this is the behavior on `main` as of writing (`876eae32`) and on the latest
> version on crates.rs (`v0.16.0`)
> I have a proposed fix here:
> [https://github.com/apache/avro/compare/main...mknaw:avro:logical-type-compat-fix]
> Perhaps there are other valid logicalTypes with this behavior. I have not
> checked every logicalType yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-3940) Failed to generate Java classes from multiple .avsc files containing same type
[
https://issues.apache.org/jira/browse/AVRO-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov updated AVRO-3940:
Fix Version/s: 1.12.0
> Failed to generate Java classes from multiple .avsc files containing same type
> --
>
> Key: AVRO-3940
> URL: https://issues.apache.org/jira/browse/AVRO-3940
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Affects Versions: 1.11.3
>Reporter: Patrick Wolleb
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: avsc-java-generator.zip, programmes-key.avsc,
> programmes-value.avsc
>
>
> I am unable to generate Java classes from two .avsc files that both contain
> an identical record. I get a SchemaParseException: Can't redefine:
> com.example.domain.Provenance.
> * schema 1: [^programmes-key.avsc]
> * schema 2: [^programmes-value.avsc]
> I am not sure I understand the generator correctly since the the check to
> throw the exception in this case was recently added for the code generation
> via an Open API yaml https://issues.apache.org/jira/browse/AVRO-3805
> Here the commit in question:
> [https://github.com/apache/avro/blame/c60e1a0cbf98412b1c65cb2d9029d32077d85574/lang/java/avro/src/main/java/org/apache/avro/Schema.java#L1753]
> [~clesaec]
> *Steps to reproduce:*
> # Download [^avsc-java-generator.zip]
> # Unzip and change into directory
> # Run ./gradlew quarkusDev --stacktrace
> # Observe SchemaParseException in output
> *Expected:*
> The generator should accept the same name and overwrite the output.
> *Result:*
> {code:java}
> Caused by: org.apache.avro.SchemaParseException: Can't redefine:
> com.example.domain.Provenance at
> org.apache.avro.Schema$Names.put(Schema.java:1604) at
> org.apache.avro.Schema$Names.add(Schema.java:1598) at
> org.apache.avro.Schema.parse(Schema.java:1774) at
> org.apache.avro.Schema.parse(Schema.java:1736) at
> org.apache.avro.Schema$Parser.parse(Schema.java:1471) at
> org.apache.avro.Schema$Parser.parse(Schema.java:1433)
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-3940) Failed to generate Java classes from multiple .avsc files containing same type
[
https://issues.apache.org/jira/browse/AVRO-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831664#comment-17831664
]
Martin Tzvetanov Grigorov commented on AVRO-3940:
-
Is there anything to be done in Avro itself ?
> Failed to generate Java classes from multiple .avsc files containing same type
> --
>
> Key: AVRO-3940
> URL: https://issues.apache.org/jira/browse/AVRO-3940
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Affects Versions: 1.11.3
>Reporter: Patrick Wolleb
>Priority: Major
> Attachments: avsc-java-generator.zip, programmes-key.avsc,
> programmes-value.avsc
>
>
> I am unable to generate Java classes from two .avsc files that both contain
> an identical record. I get a SchemaParseException: Can't redefine:
> com.example.domain.Provenance.
> * schema 1: [^programmes-key.avsc]
> * schema 2: [^programmes-value.avsc]
> I am not sure I understand the generator correctly since the the check to
> throw the exception in this case was recently added for the code generation
> via an Open API yaml https://issues.apache.org/jira/browse/AVRO-3805
> Here the commit in question:
> [https://github.com/apache/avro/blame/c60e1a0cbf98412b1c65cb2d9029d32077d85574/lang/java/avro/src/main/java/org/apache/avro/Schema.java#L1753]
> [~clesaec]
> *Steps to reproduce:*
> # Download [^avsc-java-generator.zip]
> # Unzip and change into directory
> # Run ./gradlew quarkusDev --stacktrace
> # Observe SchemaParseException in output
> *Expected:*
> The generator should accept the same name and overwrite the output.
> *Result:*
> {code:java}
> Caused by: org.apache.avro.SchemaParseException: Can't redefine:
> com.example.domain.Provenance at
> org.apache.avro.Schema$Names.put(Schema.java:1604) at
> org.apache.avro.Schema$Names.add(Schema.java:1598) at
> org.apache.avro.Schema.parse(Schema.java:1774) at
> org.apache.avro.Schema.parse(Schema.java:1736) at
> org.apache.avro.Schema$Parser.parse(Schema.java:1471) at
> org.apache.avro.Schema$Parser.parse(Schema.java:1433)
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3964) [Rust] Out-of-bounds panic
[ https://issues.apache.org/jira/browse/AVRO-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3964. - Fix Version/s: 1.12.0 Resolution: Fixed > [Rust] Out-of-bounds panic > -- > > Key: AVRO-3964 > URL: https://issues.apache.org/jira/browse/AVRO-3964 > Project: Apache Avro > Issue Type: Bug > Components: rust >Reporter: Alexander Stanovoy >Priority: Trivial > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Due to a typo, it's possible to get out-of-bounds panic on > [decode|https://github.com/apache/avro/blob/main/lang/rust/avro/src/decode.rs#L326-L327]. > It should've been `(0..symbols.len())` instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AVRO-3964) [Rust] Out-of-bounds panic
[ https://issues.apache.org/jira/browse/AVRO-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov reassigned AVRO-3964: --- Assignee: Martin Tzvetanov Grigorov > [Rust] Out-of-bounds panic > -- > > Key: AVRO-3964 > URL: https://issues.apache.org/jira/browse/AVRO-3964 > Project: Apache Avro > Issue Type: Bug > Components: rust >Reporter: Alexander Stanovoy >Assignee: Martin Tzvetanov Grigorov >Priority: Trivial > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Due to a typo, it's possible to get out-of-bounds panic on > [decode|https://github.com/apache/avro/blob/main/lang/rust/avro/src/decode.rs#L326-L327]. > It should've been `(0..symbols.len())` instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AVRO-3964) [Rust] Out-of-bounds panic
[ https://issues.apache.org/jira/browse/AVRO-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov updated AVRO-3964: Fix Version/s: 1.11.4 > [Rust] Out-of-bounds panic > -- > > Key: AVRO-3964 > URL: https://issues.apache.org/jira/browse/AVRO-3964 > Project: Apache Avro > Issue Type: Bug > Components: rust >Reporter: Alexander Stanovoy >Assignee: Martin Tzvetanov Grigorov >Priority: Trivial > Labels: pull-request-available > Fix For: 1.12.0, 1.11.4 > > Time Spent: 50m > Remaining Estimate: 0h > > Due to a typo, it's possible to get out-of-bounds panic on > [decode|https://github.com/apache/avro/blob/main/lang/rust/avro/src/decode.rs#L326-L327]. > It should've been `(0..symbols.len())` instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3960) Fix st ANYARGS warnings
[
https://issues.apache.org/jira/browse/AVRO-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3960.
-
Fix Version/s: 1.12.0
Resolution: Fixed
> Fix st ANYARGS warnings
> ---
>
> Key: AVRO-3960
> URL: https://issues.apache.org/jira/browse/AVRO-3960
> Project: Apache Avro
> Issue Type: Improvement
> Components: c
>Reporter: Sahil Kang
>Assignee: Sahil Kang
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The use of [ANYARGS by
> st.h|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/src/st.h#L23-L43]
> causes warnings such as the following:
> {quote}avro/lang/c/src/st.c:240:13: warning: passing arguments to a function
> without a prototype is deprecated in all versions of C and is not
> supported in C2x [-Wdeprecated-non-prototype]
> hash_val = do_hash(key, table);
> {quote}
>
> The use of {{ANYARGS}} can be replaced with {{void*}} and appropriate casts
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (AVRO-3960) Fix st ANYARGS warnings
[
https://issues.apache.org/jira/browse/AVRO-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov reassigned AVRO-3960:
---
Assignee: Sahil Kang
> Fix st ANYARGS warnings
> ---
>
> Key: AVRO-3960
> URL: https://issues.apache.org/jira/browse/AVRO-3960
> Project: Apache Avro
> Issue Type: Improvement
> Components: c
>Reporter: Sahil Kang
>Assignee: Sahil Kang
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The use of [ANYARGS by
> st.h|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/src/st.h#L23-L43]
> causes warnings such as the following:
> {quote}avro/lang/c/src/st.c:240:13: warning: passing arguments to a function
> without a prototype is deprecated in all versions of C and is not
> supported in C2x [-Wdeprecated-non-prototype]
> hash_val = do_hash(key, table);
> {quote}
>
> The use of {{ANYARGS}} can be replaced with {{void*}} and appropriate casts
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3945) Fix issues reported by cppcheck
[
https://issues.apache.org/jira/browse/AVRO-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3945.
-
Fix Version/s: 1.12.0
Resolution: Fixed
> Fix issues reported by cppcheck
> ---
>
> Key: AVRO-3945
> URL: https://issues.apache.org/jira/browse/AVRO-3945
> Project: Apache Avro
> Issue Type: Task
> Components: c++
>Reporter: Mikhail Koviazin
>Assignee: Mikhail Koviazin
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> This issue can be split into different stages.
>
> 1. Add missing override:
>
> {code:java}
> impl/FileStream.cc:52:5: style: Struct 'FileBufferCopyIn' has a constructor
> with 1 argument that is not explicit. [noExplicitConstructor]
> FileBufferCopyIn(const char *filename) : h_(::CreateFileA(filename,
> GENERIC_READ, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL)) {
> ^
> impl/FileStream.cc:235:5: style: Struct 'FileBufferCopyOut' has a constructor
> with 1 argument that is not explicit. [noExplicitConstructor]
> FileBufferCopyOut(const char *filename) : h_(::CreateFileA(filename,
> GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL)) {
> ^
> impl/FileStream.cc:62:10: style: The function 'seek' overrides a function in
> a base class but is not marked with a 'override' specifier. [missingOverride]
> void seek(size_t len) {
> ^
> impl/FileStream.cc:45:18: note: Virtual function in base class
> virtual void seek(size_t len) = 0;
> ^
> impl/FileStream.cc:62:10: note: Function in derived class
> void seek(size_t len) {
> ^
> impl/FileStream.cc:68:10: style: The function 'read' overrides a function in
> a base class but is not marked with a 'override' specifier. [missingOverride]
> bool read(uint8_t *b, size_t toRead, size_t ) {
> ^
> impl/FileStream.cc:46:18: note: Virtual function in base class
> virtual bool read(uint8_t *b, size_t toRead, size_t ) = 0;
> ^
> impl/FileStream.cc:68:10: note: Function in derived class
> bool read(uint8_t *b, size_t toRead, size_t ) {
> ^
> impl/FileStream.cc:245:10: style: The function 'write' overrides a function
> in a base class but is not marked with a 'override' specifier.
> [missingOverride]
> void write(const uint8_t *b, size_t len) {
> ^
> impl/FileStream.cc:229:18: note: Virtual function in base class
> virtual void write(const uint8_t *b, size_t len) = 0;
> ^
> impl/FileStream.cc:245:10: note: Function in derived class
> void write(const uint8_t *b, size_t len) {
> {code}
>
> 2. Constructors with 1 argument not marked as "explicit"
> {code:java}
> impl/json/JsonDom.hh:79:5: style: Class 'Entity' has a constructor with 1
> argument that is not explicit. [noExplicitConstructor]
> Entity(Bool v, size_t line = 0) : type_(EntityType::Bool), value_(v),
> line_(line) {}
> ^
> impl/json/JsonDom.hh:82:5: style: Class 'Entity' has a constructor with 1
> argument that is not explicit. [noExplicitConstructor]
> Entity(Long v, size_t line = 0) : type_(EntityType::Long), value_(v),
> line_(line) {}
> ^
> impl/json/JsonDom.hh:85:5: style: Class 'Entity' has a constructor with 1
> argument that is not explicit. [noExplicitConstructor]
> Entity(Double v, size_t line = 0) : type_(EntityType::Double), value_(v),
> line_(line) {}
> ^
> impl/json/JsonDom.hh:88:5: style: Class 'Entity' has a constructor with 1
> argument that is not explicit. [noExplicitConstructor]
> Entity(const std::shared_ptr , size_t line = 0) :
> type_(EntityType::String), value_(v), line_(line) {}
> ^
> impl/json/JsonDom.hh:91:5: style: Class 'Entity' has a constructor with 1
> argument that is not explicit. [noExplicitConstructor]
> Entity(const std::shared_ptr , size_t line = 0) :
> type_(EntityType::Arr), value_(v), line_(line) {}
> ^
> impl/json/JsonDom.hh:94:5: style: Class 'Entity' has a constructor with 1
> argument that is not explicit. [noExplicitConstructor]
> Entity(const std::shared_ptr , size_t line = 0) :
> type_(EntityType::Obj), value_(v), line_(line) {}
> ^
> impl/FileStream.cc:52:5: style: Struct 'FileBufferCopyIn' has a constructor
> with 1 argument that is not explicit. [noExplicitConstructor]
> FileBufferCopyIn(const char *filename) : h_(::CreateFileA(filename,
> GENERIC_READ, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL)) {
> ^
> impl/FileStream.cc:235:5: style: Struct 'FileBufferCopyOut' has a constructor
> with 1 argument that is not explicit. [noExplicitConstructor]
> FileBufferCopyOut(const char *filename) : h_(::CreateFileA(filename,
> GENERIC_WRITE, 0, NULL,
[jira] [Resolved] (AVRO-3963) Apache.Avro .NET shows vulnerabilities
[ https://issues.apache.org/jira/browse/AVRO-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3963. - Resolution: Fixed > Apache.Avro .NET shows vulnerabilities > -- > > Key: AVRO-3963 > URL: https://issues.apache.org/jira/browse/AVRO-3963 > Project: Apache Avro > Issue Type: Bug > Components: csharp >Affects Versions: 1.11.3 >Reporter: Ricardo Minguez >Priority: Major > > The NuGet Package [NuGet Gallery | Apache.Avro > 1.11.3|https://www.nuget.org/packages/Apache.Avro/1.11.3] > has dependencies on vulnerable packages, the command > dotnet list package --include-transitive --vulnerable > > shows vulnerabilities classified as High > > > Newtonsoft.Json 10.0.3 High > > https://github.com/advisories/GHSA-5crp-9r3c-p9vr > > System.Net.Http 4.3.0 High https://github.com/advisories/GHSA-7jgj-8wvc-jh57 > > System.Text.RegularExpressions 4.3.0 High > > https://github.com/advisories/GHSA-cmhx-cq75-c4mj -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AVRO-3963) Apache.Avro .NET shows vulnerabilities
[ https://issues.apache.org/jira/browse/AVRO-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828647#comment-17828647 ] Martin Tzvetanov Grigorov commented on AVRO-3963: - You could send a Pull Request that updates the dependencies at https://github.com/apache/avro/tree/main/lang/csharp ! > Apache.Avro .NET shows vulnerabilities > -- > > Key: AVRO-3963 > URL: https://issues.apache.org/jira/browse/AVRO-3963 > Project: Apache Avro > Issue Type: Bug > Components: csharp >Affects Versions: 1.11.3 >Reporter: Ricardo Minguez >Priority: Major > > The NuGet Package [NuGet Gallery | Apache.Avro > 1.11.3|https://www.nuget.org/packages/Apache.Avro/1.11.3] > has dependencies on vulnerable packages, the command > dotnet list package --include-transitive --vulnerable > > shows vulnerabilities classified as High > > > Newtonsoft.Json 10.0.3 High > > https://github.com/advisories/GHSA-5crp-9r3c-p9vr > > System.Net.Http 4.3.0 High https://github.com/advisories/GHSA-7jgj-8wvc-jh57 > > System.Text.RegularExpressions 4.3.0 High > > https://github.com/advisories/GHSA-cmhx-cq75-c4mj -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3962) [Rust] avro-derive supports extract docs from field comments
[
https://issues.apache.org/jira/browse/AVRO-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3962.
-
Fix Version/s: 1.12.0
1.11.4
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
> [Rust] avro-derive supports extract docs from field comments
>
>
> Key: AVRO-3962
> URL: https://issues.apache.org/jira/browse/AVRO-3962
> Project: Apache Avro
> Issue Type: Improvement
> Components: rust
>Reporter: Zili Chen
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When using {{#[derive(AvroSchema)]}}, it can extract record docs, but not
> field docs.
> Is it possible to extra field docs?
> Ref -
> https://github.com/apache/avro/blob/78540a1e59d8556226b9ff1484ff17212137de62/lang/rust/avro_derive/src/lib.rs#L129
> https://github.com/apache/avro/blob/78540a1e59d8556226b9ff1484ff17212137de62/lang/rust/avro_derive/src/lib.rs#L113
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3956) NPE when calling Protocol#equals or hashCode
[
https://issues.apache.org/jira/browse/AVRO-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3956.
-
Fix Version/s: 1.12.0
Assignee: Oscar Westra van Holthe - Kind
Resolution: Fixed
> NPE when calling Protocol#equals or hashCode
>
>
> Key: AVRO-3956
> URL: https://issues.apache.org/jira/browse/AVRO-3956
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Reporter: Roman Mitasov
>Assignee: Oscar Westra van Holthe - Kind
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As of documentation, {{namespace}} is optional in {{Protocol}} and thus can
> be {{{}null{}}}. {{Protocol#equals}} contains direct dereference of
> {{{}namespace{}}}, which causes {{NullPointerException}} when comparing
> Protocols with {{null}} in {{{}namespace{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-3962) [Rust] avro-derive supports extract docs from field comments
[
https://issues.apache.org/jira/browse/AVRO-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827978#comment-17827978
]
Martin Tzvetanov Grigorov commented on AVRO-3962:
-
Thanks!
> [Rust] avro-derive supports extract docs from field comments
>
>
> Key: AVRO-3962
> URL: https://issues.apache.org/jira/browse/AVRO-3962
> Project: Apache Avro
> Issue Type: Improvement
> Components: rust
>Reporter: Zili Chen
>Priority: Major
>
> When using {{#[derive(AvroSchema)]}}, it can extract record docs, but not
> field docs.
> Is it possible to extra field docs?
> Ref -
> https://github.com/apache/avro/blob/78540a1e59d8556226b9ff1484ff17212137de62/lang/rust/avro_derive/src/lib.rs#L129
> https://github.com/apache/avro/blob/78540a1e59d8556226b9ff1484ff17212137de62/lang/rust/avro_derive/src/lib.rs#L113
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-3962) [Rust] avro-derive supports extract docs from field comments
[
https://issues.apache.org/jira/browse/AVRO-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827973#comment-17827973
]
Martin Tzvetanov Grigorov commented on AVRO-3962:
-
Could you please provide a failing test case, so I could work on a fix ? Thanks!
> [Rust] avro-derive supports extract docs from field comments
>
>
> Key: AVRO-3962
> URL: https://issues.apache.org/jira/browse/AVRO-3962
> Project: Apache Avro
> Issue Type: Improvement
> Components: rust
>Reporter: Zili Chen
>Priority: Major
>
> When using {{#[derive(AvroSchema)]}}, it can extract record docs, but not
> field docs.
> Is it possible to extra field docs?
> Ref -
> https://github.com/apache/avro/blob/78540a1e59d8556226b9ff1484ff17212137de62/lang/rust/avro_derive/src/lib.rs#L129
> https://github.com/apache/avro/blob/78540a1e59d8556226b9ff1484ff17212137de62/lang/rust/avro_derive/src/lib.rs#L113
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3961) Add AVRO_INVALID to avro_type_t
[
https://issues.apache.org/jira/browse/AVRO-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3961.
-
Fix Version/s: 1.12.0
Assignee: Sahil Kang
Resolution: Fixed
> Add AVRO_INVALID to avro_type_t
> ---
>
> Key: AVRO-3961
> URL: https://issues.apache.org/jira/browse/AVRO-3961
> Project: Apache Avro
> Issue Type: Improvement
> Components: c
>Reporter: Sahil Kang
>Assignee: Sahil Kang
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> There are preexisting warnings in
> [schema.c|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/src/schema.c#L879-L886]
> and
> [datum_value.c|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/src/datum_value.c#L83-L94]
> stemming from the fact that
> [avro_type_t|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/src/avro/basics.h#L28-L44]
> does not have a default/invalid state
> However, since the public interface already exposes [EINVAL as an
> avro_type_t|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/src/datum_value.c#L95],
> we can add an {{AVRO_INVALID = EINVAL}} branch to {{avro_type_t}} while
> maintaining ABI compatibility
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3959) Avoid deprecated OSX atomic ops
[
https://issues.apache.org/jira/browse/AVRO-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3959.
-
Fix Version/s: 1.12.0
Assignee: Sahil Kang
Resolution: Fixed
> Avoid deprecated OSX atomic ops
> ---
>
> Key: AVRO-3959
> URL: https://issues.apache.org/jira/browse/AVRO-3959
> Project: Apache Avro
> Issue Type: Improvement
> Components: c
>Reporter: Sahil Kang
>Assignee: Sahil Kang
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> maOS 10.12 deprecated the {{OSAtomicIncrement32}} and {{OSAtomicDecrement32}}
> functions used in
> [avro/lang/c/src/avro/refcount.h|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/src/avro/refcount.h#L99-L114]
> which results in the following warnings:
> {quote}warning: 'OSAtomicIncrement32' is deprecated: first deprecated in
> macOS 10.12
> warning: 'OSAtomicDecrement32' is deprecated: first deprecated in macOS 10.12
> {quote}
> To remove these warnings while maintaining the exising {{avro_refcount_*}}
> signatures, we can rely on the subsequent GCC/Clang intrinsics branch
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3958) Update min CMake version to 3.5
[
https://issues.apache.org/jira/browse/AVRO-3958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3958.
-
Fix Version/s: 1.12.0
Assignee: Sahil Kang
Resolution: Fixed
> Update min CMake version to 3.5
> ---
>
> Key: AVRO-3958
> URL: https://issues.apache.org/jira/browse/AVRO-3958
> Project: Apache Avro
> Issue Type: Improvement
> Components: c
>Reporter: Sahil Kang
>Assignee: Sahil Kang
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Building with a relatively up-to-date CMake results in the following warning:
> {quote}CMake Deprecation Warning at CMakeLists.txt:19
> (cmake_minimum_required):
> Compatibility with CMake < 3.5 will be removed from a future version of
> CMake.
> Update the VERSION argument value or use a ... suffix to tell
> CMake that the project does not need compatibility with older versions.
> {quote}
> We don't use older CMake features and can update
> [cmake_minimum_required|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/CMakeLists.txt#L19]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3957) Fix typos in docs and examples
[
https://issues.apache.org/jira/browse/AVRO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3957.
-
Fix Version/s: 1.12.0
Resolution: Fixed
> Fix typos in docs and examples
> --
>
> Key: AVRO-3957
> URL: https://issues.apache.org/jira/browse/AVRO-3957
> Project: Apache Avro
> Issue Type: Bug
> Components: c
>Reporter: Sahil Kang
>Assignee: Sahil Kang
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There's a missing {{+}} trailer in
> [+avro_value_t|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/docs/index.txt#L181]
> and this [int32_t
> *p|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/examples/quickstop.c#L110]
> should be a {{const char *p}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (AVRO-3957) Fix typos in docs and examples
[
https://issues.apache.org/jira/browse/AVRO-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov reassigned AVRO-3957:
---
Assignee: Sahil Kang
> Fix typos in docs and examples
> --
>
> Key: AVRO-3957
> URL: https://issues.apache.org/jira/browse/AVRO-3957
> Project: Apache Avro
> Issue Type: Bug
> Components: c
>Reporter: Sahil Kang
>Assignee: Sahil Kang
>Priority: Trivial
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There's a missing {{+}} trailer in
> [+avro_value_t|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/docs/index.txt#L181]
> and this [int32_t
> *p|https://github.com/apache/avro/blob/9c7e14d89f80f7bea9c4d67d3ae98b86b5cff166/lang/c/examples/quickstop.c#L110]
> should be a {{const char *p}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3953) C# CodeGen.cs:503 incorrectly throws for "reserved keywords"
[
https://issues.apache.org/jira/browse/AVRO-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3953.
-
Fix Version/s: 1.12.0
Assignee: Zoltan Csizmadia
Resolution: Fixed
> C# CodeGen.cs:503 incorrectly throws for "reserved keywords"
>
>
> Key: AVRO-3953
> URL: https://issues.apache.org/jira/browse/AVRO-3953
> Project: Apache Avro
> Issue Type: Bug
> Components: csharp
>Affects Versions: 1.11.3
> Environment: Any use of the C# generator with enums that contain
> reserved keywords
>Reporter: Clemens Vasters
>Assignee: Zoltan Csizmadia
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The C# CodeGen.cs incorrectly chooses to throw when it encounters a C#
> reserved keyword as an enum member.
> In C#, any identifier that clashes with a reserved keyword can be escaped
> with a leading '@', e.g. this works:
> enum Foo
> {
> @string = 1,
> @int = 2,
> @float = 3
> }
> This is a pretty serious issue with any Avro schema that describes
> programming-related structures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-3940) Failed to generate Java classes from multiple .avsc files containing same type
[
https://issues.apache.org/jira/browse/AVRO-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov updated AVRO-3940:
Fix Version/s: (was: 1.12.0)
> Failed to generate Java classes from multiple .avsc files containing same type
> --
>
> Key: AVRO-3940
> URL: https://issues.apache.org/jira/browse/AVRO-3940
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Affects Versions: 1.11.3
>Reporter: Patrick Wolleb
>Priority: Major
> Attachments: avsc-java-generator.zip, programmes-key.avsc,
> programmes-value.avsc
>
>
> I am unable to generate Java classes from two .avsc files that both contain
> an identical record. I get a SchemaParseException: Can't redefine:
> com.example.domain.Provenance.
> * schema 1: [^programmes-key.avsc]
> * schema 2: [^programmes-value.avsc]
> I am not sure I understand the generator correctly since the the check to
> throw the exception in this case was recently added for the code generation
> via an Open API yaml https://issues.apache.org/jira/browse/AVRO-3805
> Here the commit in question:
> [https://github.com/apache/avro/blame/c60e1a0cbf98412b1c65cb2d9029d32077d85574/lang/java/avro/src/main/java/org/apache/avro/Schema.java#L1753]
> [~clesaec]
> *Steps to reproduce:*
> # Download [^avsc-java-generator.zip]
> # Unzip and change into directory
> # Run ./gradlew quarkusDev --stacktrace
> # Observe SchemaParseException in output
> *Expected:*
> The generator should accept the same name and overwrite the output.
> *Result:*
> {code:java}
> Caused by: org.apache.avro.SchemaParseException: Can't redefine:
> com.example.domain.Provenance at
> org.apache.avro.Schema$Names.put(Schema.java:1604) at
> org.apache.avro.Schema$Names.add(Schema.java:1598) at
> org.apache.avro.Schema.parse(Schema.java:1774) at
> org.apache.avro.Schema.parse(Schema.java:1736) at
> org.apache.avro.Schema$Parser.parse(Schema.java:1471) at
> org.apache.avro.Schema$Parser.parse(Schema.java:1433)
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3955) [Rust] unable to decode string enum from avro encoded data
[
https://issues.apache.org/jira/browse/AVRO-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3955.
-
Fix Version/s: 1.12.0
1.11.4
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
> [Rust] unable to decode string enum from avro encoded data
> --
>
> Key: AVRO-3955
> URL: https://issues.apache.org/jira/browse/AVRO-3955
> Project: Apache Avro
> Issue Type: Bug
> Components: rust
>Affects Versions: 1.11.3
>Reporter: Florentin
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Following the below example, the Rust crate of apache-avro is unable to
> decode a previously encoded value that contains a string enum.
>
> ```rust
> #[derive(PartialEq, Eq, Serialize, Deserialize, Debug)]
> pub struct StringEnum {
> pub source: String,
> }
> #[test]
> fn avro__decode_enum() {
> let schema_content = r#"
> {
> "name": "AccessLog",
> "namespace": "com.clevercloud.accesslogs.common.avro",
> "type": "record",
> "fields": [
> {
> "name": "source",
> "type": {
> "type": "enum",
> "name": "SourceType",
> "items": "string",
> "symbols": ["SOZU", "HAPROXY", "HAPROXY_TCP"]
> }
> }
> ]
> }
> "#;
> let schema = crate::Schema::parse_str(schema_content).unwrap();
> let data = StringEnum \{ source: "SOZU".to_string() };
> // encode into avro
> let value = crate::to_value().unwrap();
> let mut buf = std::io::Cursor::new(crate::to_avro_datum(,
> value).unwrap());
> // decode from avro
> let value = crate::from_avro_datum(, buf, None).unwrap();
> let decoded_data: StringEnum = crate::from_value().unwrap();
> // :arrow_double_up: throw => Failed to deserialize Avro value into
> value: Expected a String|Bytes|Fixed|Uuid|Union, but got Enum(0, "SOZU")
> assert_eq!(decoded_data, data);
> }
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-3954) Add Common Lisp Implementation
[ https://issues.apache.org/jira/browse/AVRO-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823129#comment-17823129 ] Martin Tzvetanov Grigorov commented on AVRO-3954: - I would suggest you to start a discussion at d...@avro.apache.org about this donation. There are no active maintainers for several of the SDKs (C/C++/Perl/JavaScript/...) and this makes it hard to convince me/us adding more SDKs. Also there is no user community for your project: - https://github.com/SahilKang/cl-avro/pulls (all PRs are just by you) - https://github.com/SahilKang/cl-avro/issues - just one issue by a user asking for a friendlier license > Add Common Lisp Implementation > -- > > Key: AVRO-3954 > URL: https://issues.apache.org/jira/browse/AVRO-3954 > Project: Apache Avro > Issue Type: New Feature >Reporter: Sahil Kang >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > [cl-avro|https://github.com/SahilKang/cl-avro] is complete enough to > integrate and further develop as part of apache avro -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3950) [rust] Some code when checking schema compatibility is never reached
[
https://issues.apache.org/jira/browse/AVRO-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov resolved AVRO-3950.
-
Fix Version/s: 1.12.0
1.11.4
Assignee: Martin Tzvetanov Grigorov
Resolution: Fixed
> [rust] Some code when checking schema compatibility is never reached
>
>
> Key: AVRO-3950
> URL: https://issues.apache.org/jira/browse/AVRO-3950
> Project: Apache Avro
> Issue Type: Improvement
>Reporter: Marcos Schroh
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.12.0, 1.11.4
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> When checking schema compatibility between schemas some code blocks are never
> reached. For example, [these lines
> |https://github.com/apache/avro/blob/main/lang/rust/avro/src/schema_compatibility.rs#L365-L374]
> are never reached because writer and readers schemas are for sure the same
> type (record) which is [previously
> compared|https://github.com/apache/avro/blob/main/lang/rust/avro/src/schema_compatibility.rs#L346].
> This issue leads to unnecessary *if let* blocks which can be suppressed and
> `Errors` that are never reached. For example the following code could be
> removed because it is know before hand that the schema is Record which it has
> a name and only one error can be retrieved.
> {code}
> let Schema::Record(RecordSchema { name: w_name, .. }) = writers_schema { ...
> }
> {code}
> *Solution*: Refactor the code and add more unittest to match_schemas function
> to clean up the unreachable code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-3952) [Python] Python test failures: TypeError: 'Buffer' object is not iterable
[
https://issues.apache.org/jira/browse/AVRO-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822537#comment-17822537
]
Martin Tzvetanov Grigorov commented on AVRO-3952:
-
{code:diff}
diff --git i/lang/py/build.sh w/lang/py/build.sh
index 000e048cf..f00013b1a 100755
--- i/lang/py/build.sh
+++ w/lang/py/build.sh
@@ -76,7 +76,10 @@ lint() {
}
test_() {
- TOX_SKIP_ENV=lint python3 -m tox --skip-missing-interpreters
+ virtualenv="$(mktemp -d)"
+ python3 -m venv "$virtualenv"
+ "$virtualenv/bin/python3" -m pip install tox
+ TOX_SKIP_ENV=lint "$virtualenv/bin/python3" -m tox
--skip-missing-interpreters
}
main() {
{code}
This patch helped to execute the tests. They pass with Python 3.10.12, but the
CI fails for Python 3.7 and 3.8
> [Python] Python test failures: TypeError: 'Buffer' object is not iterable
> -
>
> Key: AVRO-3952
> URL: https://issues.apache.org/jira/browse/AVRO-3952
> Project: Apache Avro
> Issue Type: Bug
> Components: python
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Michael A. Smith
>Priority: Major
>
> Since recently some Python tests started to fail -
> https://github.com/apache/avro/actions/runs/8111290688/job/22170288605
> {code}
> py: commands_pre[0]> mkdir -p avro/test/interop
> /home/runner/work/avro/avro/lang/py/../../build/interop/data
> py: commands_pre[1]> cp -r
> /home/runner/work/avro/avro/lang/py/../../build/interop/data avro/test/interop
> py: commands_pre[2]> coverage run -pm avro.test.gen_interop_data
> avro/interop.avsc avro/test/interop/data/py.avro
> Traceback (most recent call last):
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 103, in
> raise SystemExit(main())
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 98, in main
> generate(args.schema_path, op)
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 71, in generate
> for codec, data in output:
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 67, in
> output = ((codec, gen_data(codec, datum_writer, interop_schema)) for
> codec in CODECS_TO_VALIDATE)
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 60, in gen_data
> dfw.flush()
> File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 277, in
> flush
> self._write_block()
> File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 241, in
> _write_block
> compressed_data, compressed_data_length =
> codec.compress(uncompressed_data)
> File "/home/runner/work/avro/avro/lang/py/avro/codecs.py", line 151, in
> compress
> compressed_data = snappy.compress(data)
> File
> "/home/runner/work/avro/avro/lang/py/.tox/py/site-packages/snappy/snappy.py",
> line 78, in compress
> return bytes(_compress(data))
> TypeError: 'Buffer' object is not iterable
> py: exit 1 (1.10 seconds) /home/runner/work/avro/avro/lang/py> coverage run
> -pm avro.test.gen_interop_data avro/interop.avsc
> avro/test/interop/data/py.avro pid=2134
> py: commands_post[0]> coverage combine --append
> Combined data file .coverage.fv-az882-457.2134.989353
> py: commands_post[1]> coverage report
> {code}
> In addition running `./build.sh test` fails:
> {code}
> avro/lang/py on main [$?] via v2.7.18
> ❯ ./build.sh clean
> avro/lang/py on main [$?] via v2.7.18
> ❯ ./build.sh test
> /bin/python3: No module named tox
> {code}
> Do I need to install tox in the global libraries ? Could we (auto-)use
> virtual environment in build.sh ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (AVRO-3952) [Python] Python test failures: TypeError: 'Buffer' object is not iterable
[
https://issues.apache.org/jira/browse/AVRO-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822537#comment-17822537
]
Martin Tzvetanov Grigorov edited comment on AVRO-3952 at 3/1/24 12:39 PM:
--
{code}
diff --git i/lang/py/build.sh w/lang/py/build.sh
index 000e048cf..f00013b1a 100755
--- i/lang/py/build.sh
+++ w/lang/py/build.sh
@@ -76,7 +76,10 @@ lint() {
}
test_() {
- TOX_SKIP_ENV=lint python3 -m tox --skip-missing-interpreters
+ virtualenv="$(mktemp -d)"
+ python3 -m venv "$virtualenv"
+ "$virtualenv/bin/python3" -m pip install tox
+ TOX_SKIP_ENV=lint "$virtualenv/bin/python3" -m tox
--skip-missing-interpreters
}
main() {
{code}
This patch helped to execute the tests. They pass with Python 3.10.12, but the
CI fails for Python 3.7 and 3.8
was (Author: mgrigorov):
{code:diff}
diff --git i/lang/py/build.sh w/lang/py/build.sh
index 000e048cf..f00013b1a 100755
--- i/lang/py/build.sh
+++ w/lang/py/build.sh
@@ -76,7 +76,10 @@ lint() {
}
test_() {
- TOX_SKIP_ENV=lint python3 -m tox --skip-missing-interpreters
+ virtualenv="$(mktemp -d)"
+ python3 -m venv "$virtualenv"
+ "$virtualenv/bin/python3" -m pip install tox
+ TOX_SKIP_ENV=lint "$virtualenv/bin/python3" -m tox
--skip-missing-interpreters
}
main() {
{code}
This patch helped to execute the tests. They pass with Python 3.10.12, but the
CI fails for Python 3.7 and 3.8
> [Python] Python test failures: TypeError: 'Buffer' object is not iterable
> -
>
> Key: AVRO-3952
> URL: https://issues.apache.org/jira/browse/AVRO-3952
> Project: Apache Avro
> Issue Type: Bug
> Components: python
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Michael A. Smith
>Priority: Major
>
> Since recently some Python tests started to fail -
> https://github.com/apache/avro/actions/runs/8111290688/job/22170288605
> {code}
> py: commands_pre[0]> mkdir -p avro/test/interop
> /home/runner/work/avro/avro/lang/py/../../build/interop/data
> py: commands_pre[1]> cp -r
> /home/runner/work/avro/avro/lang/py/../../build/interop/data avro/test/interop
> py: commands_pre[2]> coverage run -pm avro.test.gen_interop_data
> avro/interop.avsc avro/test/interop/data/py.avro
> Traceback (most recent call last):
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 103, in
> raise SystemExit(main())
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 98, in main
> generate(args.schema_path, op)
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 71, in generate
> for codec, data in output:
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 67, in
> output = ((codec, gen_data(codec, datum_writer, interop_schema)) for
> codec in CODECS_TO_VALIDATE)
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 60, in gen_data
> dfw.flush()
> File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 277, in
> flush
> self._write_block()
> File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 241, in
> _write_block
> compressed_data, compressed_data_length =
> codec.compress(uncompressed_data)
> File "/home/runner/work/avro/avro/lang/py/avro/codecs.py", line 151, in
> compress
> compressed_data = snappy.compress(data)
> File
> "/home/runner/work/avro/avro/lang/py/.tox/py/site-packages/snappy/snappy.py",
> line 78, in compress
> return bytes(_compress(data))
> TypeError: 'Buffer' object is not iterable
> py: exit 1 (1.10 seconds) /home/runner/work/avro/avro/lang/py> coverage run
> -pm avro.test.gen_interop_data avro/interop.avsc
> avro/test/interop/data/py.avro pid=2134
> py: commands_post[0]> coverage combine --append
> Combined data file .coverage.fv-az882-457.2134.989353
> py: commands_post[1]> coverage report
> {code}
> In addition running `./build.sh test` fails:
> {code}
> avro/lang/py on main [$?] via v2.7.18
> ❯ ./build.sh clean
> avro/lang/py on main [$?] via v2.7.18
> ❯ ./build.sh test
> /bin/python3: No module named tox
> {code}
> Do I need to install tox in the global libraries ? Could we (auto-)use
> virtual environment in build.sh ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (AVRO-3952) [Python] Python test failures: TypeError: 'Buffer' object is not iterable
[
https://issues.apache.org/jira/browse/AVRO-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov updated AVRO-3952:
Description:
Since recently some Python tests started to fail -
https://github.com/apache/avro/actions/runs/8111290688/job/22170288605
{code}
py: commands_pre[0]> mkdir -p avro/test/interop
/home/runner/work/avro/avro/lang/py/../../build/interop/data
py: commands_pre[1]> cp -r
/home/runner/work/avro/avro/lang/py/../../build/interop/data avro/test/interop
py: commands_pre[2]> coverage run -pm avro.test.gen_interop_data
avro/interop.avsc avro/test/interop/data/py.avro
Traceback (most recent call last):
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 103, in
raise SystemExit(main())
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 98, in main
generate(args.schema_path, op)
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 71, in generate
for codec, data in output:
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 67, in
output = ((codec, gen_data(codec, datum_writer, interop_schema)) for codec
in CODECS_TO_VALIDATE)
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 60, in gen_data
dfw.flush()
File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 277, in
flush
self._write_block()
File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 241, in
_write_block
compressed_data, compressed_data_length = codec.compress(uncompressed_data)
File "/home/runner/work/avro/avro/lang/py/avro/codecs.py", line 151, in
compress
compressed_data = snappy.compress(data)
File
"/home/runner/work/avro/avro/lang/py/.tox/py/site-packages/snappy/snappy.py",
line 78, in compress
return bytes(_compress(data))
TypeError: 'Buffer' object is not iterable
py: exit 1 (1.10 seconds) /home/runner/work/avro/avro/lang/py> coverage run -pm
avro.test.gen_interop_data avro/interop.avsc avro/test/interop/data/py.avro
pid=2134
py: commands_post[0]> coverage combine --append
Combined data file .coverage.fv-az882-457.2134.989353
py: commands_post[1]> coverage report
{code}
In addition running `./build.sh test` fails:
{code}
avro/lang/py on main [$?] via v2.7.18
❯ ./build.sh clean
avro/lang/py on main [$?] via v2.7.18
❯ ./build.sh test
/bin/python3: No module named tox
{code}
Do I need to install tox in the global libraries ? Could we (auto-)use virtual
environment in build.sh ?
was:
Since recently some Python tests started to fail -
https://github.com/apache/avro/actions/runs/8111290688/job/22170288605
{code}
py: commands_pre[0]> mkdir -p avro/test/interop
/home/runner/work/avro/avro/lang/py/../../build/interop/data
py: commands_pre[1]> cp -r
/home/runner/work/avro/avro/lang/py/../../build/interop/data avro/test/interop
py: commands_pre[2]> coverage run -pm avro.test.gen_interop_data
avro/interop.avsc avro/test/interop/data/py.avro
Traceback (most recent call last):
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 103, in
raise SystemExit(main())
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 98, in main
generate(args.schema_path, op)
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 71, in generate
for codec, data in output:
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 67, in
output = ((codec, gen_data(codec, datum_writer, interop_schema)) for codec
in CODECS_TO_VALIDATE)
File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
line 60, in gen_data
dfw.flush()
File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 277, in
flush
self._write_block()
File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 241, in
_write_block
compressed_data, compressed_data_length = codec.compress(uncompressed_data)
File "/home/runner/work/avro/avro/lang/py/avro/codecs.py", line 151, in
compress
compressed_data = snappy.compress(data)
File
"/home/runner/work/avro/avro/lang/py/.tox/py/site-packages/snappy/snappy.py",
line 78, in compress
return bytes(_compress(data))
TypeError: 'Buffer' object is not iterable
py: exit 1 (1.10 seconds) /home/runner/work/avro/avro/lang/py> coverage run -pm
avro.test.gen_interop_data avro/interop.avsc avro/test/interop/data/py.avro
pid=2134
py: commands_post[0]> coverage combine --append
Combined data file .coverage.fv-az882-457.2134.989353
py: commands_post[1]> coverage report
{code}
> [Python] Python test failures: TypeError: 'Buffer' object is not iterable
> -
>
> Key: AVRO-3952
> URL:
[jira] [Assigned] (AVRO-3952) [Python] Python test failures: TypeError: 'Buffer' object is not iterable
[
https://issues.apache.org/jira/browse/AVRO-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Tzvetanov Grigorov reassigned AVRO-3952:
---
> [Python] Python test failures: TypeError: 'Buffer' object is not iterable
> -
>
> Key: AVRO-3952
> URL: https://issues.apache.org/jira/browse/AVRO-3952
> Project: Apache Avro
> Issue Type: Bug
> Components: python
>Reporter: Martin Tzvetanov Grigorov
>Assignee: Michael A. Smith
>Priority: Major
>
> Since recently some Python tests started to fail -
> https://github.com/apache/avro/actions/runs/8111290688/job/22170288605
> {code}
> py: commands_pre[0]> mkdir -p avro/test/interop
> /home/runner/work/avro/avro/lang/py/../../build/interop/data
> py: commands_pre[1]> cp -r
> /home/runner/work/avro/avro/lang/py/../../build/interop/data avro/test/interop
> py: commands_pre[2]> coverage run -pm avro.test.gen_interop_data
> avro/interop.avsc avro/test/interop/data/py.avro
> Traceback (most recent call last):
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 103, in
> raise SystemExit(main())
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 98, in main
> generate(args.schema_path, op)
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 71, in generate
> for codec, data in output:
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 67, in
> output = ((codec, gen_data(codec, datum_writer, interop_schema)) for
> codec in CODECS_TO_VALIDATE)
> File "/home/runner/work/avro/avro/lang/py/avro/test/gen_interop_data.py",
> line 60, in gen_data
> dfw.flush()
> File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 277, in
> flush
> self._write_block()
> File "/home/runner/work/avro/avro/lang/py/avro/datafile.py", line 241, in
> _write_block
> compressed_data, compressed_data_length =
> codec.compress(uncompressed_data)
> File "/home/runner/work/avro/avro/lang/py/avro/codecs.py", line 151, in
> compress
> compressed_data = snappy.compress(data)
> File
> "/home/runner/work/avro/avro/lang/py/.tox/py/site-packages/snappy/snappy.py",
> line 78, in compress
> return bytes(_compress(data))
> TypeError: 'Buffer' object is not iterable
> py: exit 1 (1.10 seconds) /home/runner/work/avro/avro/lang/py> coverage run
> -pm avro.test.gen_interop_data avro/interop.avsc
> avro/test/interop/data/py.avro pid=2134
> py: commands_post[0]> coverage combine --append
> Combined data file .coverage.fv-az882-457.2134.989353
> py: commands_post[1]> coverage report
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (AVRO-3950) [rust] Some code when checking schema compatibility is never reached
[
https://issues.apache.org/jira/browse/AVRO-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821222#comment-17821222
]
Martin Tzvetanov Grigorov edited comment on AVRO-3950 at 2/27/24 1:08 PM:
--
Please do!
It would be nice if you start your work with the unit tests and then with the
refactoring!
was (Author: mgrigorov):
Please do!
> [rust] Some code when checking schema compatibility is never reached
>
>
> Key: AVRO-3950
> URL: https://issues.apache.org/jira/browse/AVRO-3950
> Project: Apache Avro
> Issue Type: Improvement
>Reporter: Marcos Schroh
>Priority: Minor
>
> When checking schema compatibility between schemas some code blocks are never
> reached. For example, [these lines
> |https://github.com/apache/avro/blob/main/lang/rust/avro/src/schema_compatibility.rs#L365-L374]
> are never reached because writer and readers schemas are for sure the same
> type (record) which is [previously
> compared|https://github.com/apache/avro/blob/main/lang/rust/avro/src/schema_compatibility.rs#L346].
> This issue leads to unnecessary *if let* blocks which can be suppressed and
> `Errors` that are never reached. For example the following code could be
> removed because it is know before hand that the schema is Record which it has
> a name and only one error can be retrieved.
> {code}
> let Schema::Record(RecordSchema { name: w_name, .. }) = writers_schema { ...
> }
> {code}
> *Solution*: Refactor the code and add more unittest to match_schemas function
> to clean up the unreachable code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AVRO-3950) [rust] Some code when checking schema compatibility is never reached
[
https://issues.apache.org/jira/browse/AVRO-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821222#comment-17821222
]
Martin Tzvetanov Grigorov commented on AVRO-3950:
-
Please do!
> [rust] Some code when checking schema compatibility is never reached
>
>
> Key: AVRO-3950
> URL: https://issues.apache.org/jira/browse/AVRO-3950
> Project: Apache Avro
> Issue Type: Improvement
>Reporter: Marcos Schroh
>Priority: Minor
>
> When checking schema compatibility between schemas some code blocks are never
> reached. For example, [these lines
> |https://github.com/apache/avro/blob/main/lang/rust/avro/src/schema_compatibility.rs#L365-L374]
> are never reached because writer and readers schemas are for sure the same
> type (record) which is [previously
> compared|https://github.com/apache/avro/blob/main/lang/rust/avro/src/schema_compatibility.rs#L346].
> This issue leads to unnecessary *if let* blocks which can be suppressed and
> `Errors` that are never reached. For example the following code could be
> removed because it is know before hand that the schema is Record which it has
> a name and only one error can be retrieved.
> {code}
> let Schema::Record(RecordSchema { name: w_name, .. }) = writers_schema { ...
> }
> {code}
> *Solution*: Refactor the code and add more unittest to match_schemas function
> to clean up the unreachable code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (AVRO-3949) [Rust]: Add support for serde to apache_avro::Decimal
[ https://issues.apache.org/jira/browse/AVRO-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3949. - Fix Version/s: 1.12.0 1.11.4 Resolution: Fixed > [Rust]: Add support for serde to apache_avro::Decimal > - > > Key: AVRO-3949 > URL: https://issues.apache.org/jira/browse/AVRO-3949 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Reporter: Martin Tzvetanov Grigorov >Assignee: Martin Tzvetanov Grigorov >Priority: Major > Labels: pull-request-available > Fix For: 1.12.0, 1.11.4 > > Time Spent: 20m > Remaining Estimate: 0h > > rsgen-avro crate exposed that apache_avro::Decimal does not implement > * serde::Serialize > * serde::Deserialize > * Eq > traits > https://github.com/lerouxrgd/rsgen-avro/issues/61 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (AVRO-3948) [Rust] Re-export bigdecimal::BigDecimal as apache_avro::BigDecimal
[ https://issues.apache.org/jira/browse/AVRO-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov resolved AVRO-3948. - Fix Version/s: 1.12.0 1.11.4 Resolution: Fixed > [Rust] Re-export bigdecimal::BigDecimal as apache_avro::BigDecimal > -- > > Key: AVRO-3948 > URL: https://issues.apache.org/jira/browse/AVRO-3948 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Reporter: Martin Tzvetanov Grigorov >Assignee: Martin Tzvetanov Grigorov >Priority: Major > Labels: pull-request-available > Fix For: 1.12.0, 1.11.4 > > Time Spent: 20m > Remaining Estimate: 0h > > Support for BigDecimal has been added with AVRO-3779. > rsgen-avro project needs the bigdecimal::BigDecimal struct re-exported as > apache_avro::BigDecimal for better UX and forward compatibility. > https://github.com/lerouxrgd/rsgen-avro/issues/61#issuecomment-1962083160 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AVRO-3949) [Rust]: Add support for serde to apache_avro::Decimal
[ https://issues.apache.org/jira/browse/AVRO-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov reassigned AVRO-3949: --- > [Rust]: Add support for serde to apache_avro::Decimal > - > > Key: AVRO-3949 > URL: https://issues.apache.org/jira/browse/AVRO-3949 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Reporter: Martin Tzvetanov Grigorov >Assignee: Martin Tzvetanov Grigorov >Priority: Major > > rsgen-avro crate exposed that apache_avro::Decimal does not implement > * serde::Serialize > * serde::Deserialize > * Eq > traits > https://github.com/lerouxrgd/rsgen-avro/issues/61 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (AVRO-3948) [Rust] Re-export bigdecimal::BigDecimal as apache_avro::BigDecimal
[ https://issues.apache.org/jira/browse/AVRO-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov reassigned AVRO-3948: --- > [Rust] Re-export bigdecimal::BigDecimal as apache_avro::BigDecimal > -- > > Key: AVRO-3948 > URL: https://issues.apache.org/jira/browse/AVRO-3948 > Project: Apache Avro > Issue Type: Improvement > Components: rust >Reporter: Martin Tzvetanov Grigorov >Assignee: Martin Tzvetanov Grigorov >Priority: Major > > Support for BigDecimal has been added with AVRO-3779. > rsgen-avro project needs the bigdecimal::BigDecimal struct re-exported as > apache_avro::BigDecimal for better UX and forward compatibility. > https://github.com/lerouxrgd/rsgen-avro/issues/61#issuecomment-1962083160 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (AVRO-3912) Issue with deserialization for BigDecimal in rust
[ https://issues.apache.org/jira/browse/AVRO-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Tzvetanov Grigorov updated AVRO-3912: Component/s: rust > Issue with deserialization for BigDecimal in rust > - > > Key: AVRO-3912 > URL: https://issues.apache.org/jira/browse/AVRO-3912 > Project: Apache Avro > Issue Type: Bug > Components: rust >Reporter: Christophe Le Saec >Assignee: Christophe Le Saec >Priority: Major > Labels: pull-request-available > Fix For: 1.12.0, 1.11.4 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Deserialization with reader does not work in rust -- This message was sent by Atlassian Jira (v8.20.10#820010)
