Re: Avro C#: Target .NET Standard Only

[Brian Lachniet]

Thank you for your feedback. I will go ahead and make a Jira issue and
start making these changes.

I like the idea of treating this as a minor change rather than a breaking
change. If there are no objections, that's the way I will proceed.

As far as download counts: v1.9.0 was the first time the NuGet package was
"officially" released on NuGet. That version has seen only 446 downloads
since its release (See the NuGet package page here
).


On Fri, Jun 14, 2019 at 3:42 AM Driesprong, Fokko 
wrote:

> Hi Brian,
>
> Do we have something like the number of downloads? To measure how much this
> is still being used. I haven't touched a Windows machine in a couple of
> years, so for me, it isn't super relevant.
>
> There are some different opinions on if this is breaking or not. At the
> Parquet project, we had a similar discussion:
>
> https://lists.apache.org/thread.html/0df375609a2faf384cebc9f0423eead7ca358b73953b07652d7d6a6e@%3Cdev.parquet.apache.org%3E
> Parquet wants to drop some old modules that aren't used that much anymore,
> you could also argue that you stop releasing the .Net standard.
>
> Cheers, Fokko Driesprong
>
>
> Op vr 14 jun. 2019 om 07:02 schreef Patrick Farry <
> patrick.s.fa...@gmail.com
> >:
>
> > Hi Brian,
> >
> > This is good for us at Pitney Bowes, but we don't do anything on Windows
> so
> > its all upside as far as we are concerned.
> >
> > I'd also add that the current release doesnt build out of the box on
> macos
> > with VS code.
> > It would be great if we could just build with 'dotnet build' etc. so this
> > could be another reason to make this change.
> >
> > patrick
> >
> > On Thu, Jun 13, 2019, 7:08 PM Brian Lachniet 
> wrote:
> >
> > > I would like to propose that we update the main Avro C# project to
> target
> > > .NET Standard only. I will lay out a couple reasons below, but first
> > let's
> > > start with a little context.
> > >
> > > You can see the different frameworks that the C# project currently
> > targets
> > > here in the README
> > > <
> > https://github.com/apache/avro/tree/master/lang/csharp#target-frameworks
> > > >.
> > > We updated the main Avro library to target .NET Standard with the
> release
> > > of v1.9.0. However, we continue to target the .NET Framework v4.0 as
> > well.
> > > This allows users that are targeting .NET Framework versions between
> 4.0
> > > and 4.6.1 to still use the library. As you can see in this table on
> .NET
> > > Standard
> > > <
> > >
> >
> https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-implementation-support
> > > >compatibility,
> > > as long as you are targeting .NET Framework 4.6.1 or later OR .NET Core
> > 2.0
> > > or later, you can use a library that targets .NET Standard.
> > >
> > > To be clear, we are not dropping support for all of .NET Framework. We
> > > would drop support for for any version of .NET Framework before v4.6.1.
> > >
> > > This change will simplify our release process. At this time, we can
> only
> > > build a NuGet package that contains both .NET Framework and .NET
> Standard
> > > binaries on Windows. This means that after the "official" release is
> > > created and deployed, I have to rebuild the project on my Windows
> machine
> > > before publishing the package to nuget.org. With this change, we would
> > > only
> > > create .NET Standard binaries, which means that we could build the
> NuGet
> > > package on a Linux machine. Then, we could publish the NuGet directly
> > from
> > > the "official" build to nuget.org. No more side channel builds.
> > >
> > > This change will also simplify development, particularly when
> developing
> > on
> > > non-Windows platforms. I think it's still a good idea to run our unit
> > tests
> > > on .NET Framework in addition to Core, but we could make it so that
> those
> > > are only run when run on Windows.
> > >
> > > This is a breaking change for the C# library, so we would need to save
> > this
> > > for the 1.10 release.
> > >
> > > Does anyone have any objections, questions or concerns?
> > >
> > > Thanks,
> > >
> > > --
> > >
> > > [image: 51b630b05e01a6d5134ccfd520f547c4.png]
> > >
> > > Brian Lachniet
> > >
> > > Software Engineer
> > >
> > > E: blachn...@gmail.com | blachniet.com 
> > >
> > >  
> > >
> >
>


-- 

[image: 51b630b05e01a6d5134ccfd520f547c4.png]

Brian Lachniet

Software Engineer

E: blachn...@gmail.com | blachniet.com 

 

[jira] [Created] (AVRO-2421) Allow multiple @AvroAlias annotations on java classes and their fields

[Johannes Schulte (JIRA)]

Johannes Schulte created AVRO-2421:
--

 Summary: Allow multiple @AvroAlias annotations on java classes and 
their fields
 Key: AVRO-2421
 URL: https://issues.apache.org/jira/browse/AVRO-2421
 Project: Apache Avro
  Issue Type: Improvement
Reporter: Johannes Schulte
Assignee: Johannes Schulte


The avro schema specification allows defining multiple aliases for fields and 
records and this can be useful especially when using java classes to define the 
schema (refactoring & namespace/package changes).

With the introduction of @Repeatable in java 1.8 there exists an easy way to 
expose this flexibility in the Reflect-based world. This patch enables defining 
multiple @AvroAlias annotation on both fields and classes 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (AVRO-2420) Python3 - missing tests for py3 version

[Gennady Feldman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gennady Feldman updated AVRO-2420:
--
Description: Looks like the tests for python are only in the python 2 
version . There are no tests? for py3 (python3?)  (was: Looks like the test for 
python are only in the python 2 version . There are no tests? for py3 
(python3?))

> Python3 - missing tests for py3 version
> ---
>
> Key: AVRO-2420
> URL: https://issues.apache.org/jira/browse/AVRO-2420
> Project: Apache Avro
>  Issue Type: Test
>  Components: python
>Affects Versions: 1.9.0
>Reporter: Gennady Feldman
>Priority: Major
>
> Looks like the tests for python are only in the python 2 version . There are 
> no tests? for py3 (python3?)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (AVRO-2420) Python3 - missing tests for py3 version

[Gennady Feldman (JIRA)]

Gennady Feldman created AVRO-2420:
-

 Summary: Python3 - missing tests for py3 version
 Key: AVRO-2420
 URL: https://issues.apache.org/jira/browse/AVRO-2420
 Project: Apache Avro
  Issue Type: Test
  Components: python
Affects Versions: 1.9.0
Reporter: Gennady Feldman


Looks like the test for python are only in the python 2 version . There are no 
tests? for py3 (python3?)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863845#comment-16863845
 ] 

Hudson commented on AVRO-2400:
--

SUCCESS: Integrated in Jenkins build AvroJava #676 (See 
[https://builds.apache.org/job/AvroJava/676/])
AVRO-2400: Make schema resolution behave the same as previous versions (fokko: 
[https://github.com/apache/avro/commit/aa972ced3c001e0d9d8de6cd5013a1cb3b989551])
* (edit) lang/java/avro/src/main/java/org/apache/avro/SchemaCompatibility.java
* (edit) 
lang/java/avro/src/test/java/org/apache/avro/TestSchemaCompatibilityMultiple.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/Resolver.java
* (edit) 
lang/java/avro/src/main/java/org/apache/avro/io/parsing/ResolvingGrammarGenerator.java
* (edit) doc/src/content/xdocs/spec.xml
* (edit) lang/java/avro/src/test/java/org/apache/avro/TestSchemas.java
* (edit) 
lang/java/avro/src/test/java/org/apache/avro/TestSchemaCompatibilityNameMismatch.java
* (edit) 
lang/java/avro/src/test/java/org/apache/avro/TestSchemaCompatibility.java
* (edit) lang/java/avro/src/test/java/org/apache/avro/TestSchemaValidation.java


> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863829#comment-16863829
 ] 

ASF subversion and git services commented on AVRO-2400:
---

Commit 907558c65fa754a53b4a9493cebe692aecddfe02 in avro's branch 
refs/heads/branch-1.9 from jacobtolar
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=907558c ]

AVRO-2400: Make schema resolution behave the same as previous versions (#526)

* [AVRO-2400] Make schema resolution behave the same as previous versions

* AVRO-2400 make same schema resolution changes to SchemaCompatibility

* make style check happy

* fix failing tests

* AVRO-2400 fix checkstyle issue

(cherry picked from commit aa972ced3c001e0d9d8de6cd5013a1cb3b989551)


> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863830#comment-16863830
 ] 

ASF subversion and git services commented on AVRO-2400:
---

Commit 907558c65fa754a53b4a9493cebe692aecddfe02 in avro's branch 
refs/heads/branch-1.9 from jacobtolar
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=907558c ]

AVRO-2400: Make schema resolution behave the same as previous versions (#526)

* [AVRO-2400] Make schema resolution behave the same as previous versions

* AVRO-2400 make same schema resolution changes to SchemaCompatibility

* make style check happy

* fix failing tests

* AVRO-2400 fix checkstyle issue

(cherry picked from commit aa972ced3c001e0d9d8de6cd5013a1cb3b989551)


> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863831#comment-16863831
 ] 

ASF subversion and git services commented on AVRO-2400:
---

Commit 907558c65fa754a53b4a9493cebe692aecddfe02 in avro's branch 
refs/heads/branch-1.9 from jacobtolar
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=907558c ]

AVRO-2400: Make schema resolution behave the same as previous versions (#526)

* [AVRO-2400] Make schema resolution behave the same as previous versions

* AVRO-2400 make same schema resolution changes to SchemaCompatibility

* make style check happy

* fix failing tests

* AVRO-2400 fix checkstyle issue

(cherry picked from commit aa972ced3c001e0d9d8de6cd5013a1cb3b989551)


> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863828#comment-16863828
 ] 

ASF subversion and git services commented on AVRO-2400:
---

Commit 907558c65fa754a53b4a9493cebe692aecddfe02 in avro's branch 
refs/heads/branch-1.9 from jacobtolar
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=907558c ]

AVRO-2400: Make schema resolution behave the same as previous versions (#526)

* [AVRO-2400] Make schema resolution behave the same as previous versions

* AVRO-2400 make same schema resolution changes to SchemaCompatibility

* make style check happy

* fix failing tests

* AVRO-2400 fix checkstyle issue

(cherry picked from commit aa972ced3c001e0d9d8de6cd5013a1cb3b989551)


> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863813#comment-16863813
 ] 

ASF subversion and git services commented on AVRO-2400:
---

Commit aa972ced3c001e0d9d8de6cd5013a1cb3b989551 in avro's branch 
refs/heads/master from jacobtolar
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=aa972ce ]

AVRO-2400: Make schema resolution behave the same as previous versions (#526)

* [AVRO-2400] Make schema resolution behave the same as previous versions

* AVRO-2400 make same schema resolution changes to SchemaCompatibility

* make style check happy

* fix failing tests

* AVRO-2400 fix checkstyle issue


> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863812#comment-16863812
 ] 

ASF subversion and git services commented on AVRO-2400:
---

Commit aa972ced3c001e0d9d8de6cd5013a1cb3b989551 in avro's branch 
refs/heads/master from jacobtolar
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=aa972ce ]

AVRO-2400: Make schema resolution behave the same as previous versions (#526)

* [AVRO-2400] Make schema resolution behave the same as previous versions

* AVRO-2400 make same schema resolution changes to SchemaCompatibility

* make style check happy

* fix failing tests

* AVRO-2400 fix checkstyle issue


> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863814#comment-16863814
 ] 

ASF subversion and git services commented on AVRO-2400:
---

Commit aa972ced3c001e0d9d8de6cd5013a1cb3b989551 in avro's branch 
refs/heads/master from jacobtolar
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=aa972ce ]

AVRO-2400: Make schema resolution behave the same as previous versions (#526)

* [AVRO-2400] Make schema resolution behave the same as previous versions

* AVRO-2400 make same schema resolution changes to SchemaCompatibility

* make style check happy

* fix failing tests

* AVRO-2400 fix checkstyle issue


> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[Fokko Driesprong (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fokko Driesprong resolved AVRO-2400.

Resolution: Fixed

> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2400) Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863811#comment-16863811
 ] 

ASF subversion and git services commented on AVRO-2400:
---

Commit aa972ced3c001e0d9d8de6cd5013a1cb3b989551 in avro's branch 
refs/heads/master from jacobtolar
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=aa972ce ]

AVRO-2400: Make schema resolution behave the same as previous versions (#526)

* [AVRO-2400] Make schema resolution behave the same as previous versions

* AVRO-2400 make same schema resolution changes to SchemaCompatibility

* make style check happy

* fix failing tests

* AVRO-2400 fix checkstyle issue


> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Jacob Tolar
>Assignee: Jacob Tolar
>Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema 
> have an array of records with different full names (e.g. different 
> namespace). 
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.avro.Resolver$ReaderUnion cannot be cast to 
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the 
> jiras and code, I don't believe this was intentional ( AVRO-2275,  
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
>   ).
>  
> It looks like there were some attempts to keep compatibility ( 
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
>  , e.g. see the commented out check for w.getFullName() in resolve()) but 
> this case was missed.
>  
> See this simple example to reproduce. 
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Avro C#: Target .NET Standard Only

[Driesprong, Fokko]

Hi Brian,

Do we have something like the number of downloads? To measure how much this
is still being used. I haven't touched a Windows machine in a couple of
years, so for me, it isn't super relevant.

There are some different opinions on if this is breaking or not. At the
Parquet project, we had a similar discussion:
https://lists.apache.org/thread.html/0df375609a2faf384cebc9f0423eead7ca358b73953b07652d7d6a6e@%3Cdev.parquet.apache.org%3E
Parquet wants to drop some old modules that aren't used that much anymore,
you could also argue that you stop releasing the .Net standard.

Cheers, Fokko Driesprong


Op vr 14 jun. 2019 om 07:02 schreef Patrick Farry :

> Hi Brian,
>
> This is good for us at Pitney Bowes, but we don't do anything on Windows so
> its all upside as far as we are concerned.
>
> I'd also add that the current release doesnt build out of the box on macos
> with VS code.
> It would be great if we could just build with 'dotnet build' etc. so this
> could be another reason to make this change.
>
> patrick
>
> On Thu, Jun 13, 2019, 7:08 PM Brian Lachniet  wrote:
>
> > I would like to propose that we update the main Avro C# project to target
> > .NET Standard only. I will lay out a couple reasons below, but first
> let's
> > start with a little context.
> >
> > You can see the different frameworks that the C# project currently
> targets
> > here in the README
> > <
> https://github.com/apache/avro/tree/master/lang/csharp#target-frameworks
> > >.
> > We updated the main Avro library to target .NET Standard with the release
> > of v1.9.0. However, we continue to target the .NET Framework v4.0 as
> well.
> > This allows users that are targeting .NET Framework versions between 4.0
> > and 4.6.1 to still use the library. As you can see in this table on .NET
> > Standard
> > <
> >
> https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-implementation-support
> > >compatibility,
> > as long as you are targeting .NET Framework 4.6.1 or later OR .NET Core
> 2.0
> > or later, you can use a library that targets .NET Standard.
> >
> > To be clear, we are not dropping support for all of .NET Framework. We
> > would drop support for for any version of .NET Framework before v4.6.1.
> >
> > This change will simplify our release process. At this time, we can only
> > build a NuGet package that contains both .NET Framework and .NET Standard
> > binaries on Windows. This means that after the "official" release is
> > created and deployed, I have to rebuild the project on my Windows machine
> > before publishing the package to nuget.org. With this change, we would
> > only
> > create .NET Standard binaries, which means that we could build the NuGet
> > package on a Linux machine. Then, we could publish the NuGet directly
> from
> > the "official" build to nuget.org. No more side channel builds.
> >
> > This change will also simplify development, particularly when developing
> on
> > non-Windows platforms. I think it's still a good idea to run our unit
> tests
> > on .NET Framework in addition to Core, but we could make it so that those
> > are only run when run on Windows.
> >
> > This is a breaking change for the C# library, so we would need to save
> this
> > for the 1.10 release.
> >
> > Does anyone have any objections, questions or concerns?
> >
> > Thanks,
> >
> > --
> >
> > [image: 51b630b05e01a6d5134ccfd520f547c4.png]
> >
> > Brian Lachniet
> >
> > Software Engineer
> >
> > E: blachn...@gmail.com | blachniet.com 
> >
> >  
> >
>