[jira] [Created] (AVRO-2174) Enums with spaces are accepted

[Harshal Dalvi (JIRA)]

Harshal Dalvi created AVRO-2174:
---

 Summary: Enums with spaces are accepted
 Key: AVRO-2174
 URL: https://issues.apache.org/jira/browse/AVRO-2174
 Project: Avro
  Issue Type: Bug
  Components: python
Affects Versions: 1.8.2
Reporter: Harshal Dalvi


The Avro spec does not allow for spaces *' '*  in enums. However, Python Avro 
does not error out of reject enums with spaces in them.



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

[jira] [Updated] (AVRO-2174) Enums with spaces are accepted

[Harshal Dalvi (JIRA)]

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

Harshal Dalvi updated AVRO-2174:

Description: 
The Avro spec does not allow for spaces *' '*  in enums. However, Python Avro 
does not error out or reject enums with spaces in them.

This is an example of a part of a schema which was accepted by the python 
package:

{code}

{
"default": null,
"type": [
"null",
{
"symbols": [
"top left",
"top center",
"top right",
"center left",
"center center",
"center right",
"bottom left",
"bottom center",
"bottom right"
],
"type": "enum",
"namespace": "",
"name": "postion_enum"
}

{code}

 

The same schema, when read by the Java library errors out at *top left* as 
expected:

{code}

Caused by: org.shaded.apache.avro.SchemaParseException: Illegal character in: 
top left
 at org.shaded.apache.avro.Schema.validateName(Schema.java:1151)
 at org.shaded.apache.avro.Schema.access$200(Schema.java:81)
 at org.shaded.apache.avro.Schema$EnumSchema.(Schema.java:749)
 at org.shaded.apache.avro.Schema.parse(Schema.java:1300)
 at org.shaded.apache.avro.Schema.parse(Schema.java:1340)
 at org.shaded.apache.avro.Schema.parse(Schema.java:1269)
 at org.shaded.apache.avro.Schema$Parser.parse(Schema.java:1032)
 at org.shaded.apache.avro.Schema$Parser.parse(Schema.java:1020)

{code}

  was:The Avro spec does not allow for spaces *' '*  in enums. However, Python 
Avro does not error out or reject enums with spaces in them.


> Enums with spaces are accepted
> --
>
> Key: AVRO-2174
> URL: https://issues.apache.org/jira/browse/AVRO-2174
> Project: Avro
>  Issue Type: Bug
>  Components: python
>Affects Versions: 1.8.2
>Reporter: Harshal Dalvi
>Priority: Major
>
> The Avro spec does not allow for spaces *' '*  in enums. However, Python Avro 
> does not error out or reject enums with spaces in them.
> This is an example of a part of a schema which was accepted by the python 
> package:
> {code}
> {
> "default": null,
> "type": [
> "null",
> {
> "symbols": [
> "top left",
> "top center",
> "top right",
> "center left",
> "center center",
> "center right",
> "bottom left",
> "bottom center",
> "bottom right"
> ],
> "type": "enum",
> "namespace": "",
> "name": "postion_enum"
> }
> {code}
>  
> The same schema, when read by the Java library errors out at *top left* as 
> expected:
> {code}
> Caused by: org.shaded.apache.avro.SchemaParseException: Illegal character in: 
> top left
>  at org.shaded.apache.avro.Schema.validateName(Schema.java:1151)
>  at org.shaded.apache.avro.Schema.access$200(Schema.java:81)
>  at org.shaded.apache.avro.Schema$EnumSchema.(Schema.java:749)
>  at org.shaded.apache.avro.Schema.parse(Schema.java:1300)
>  at org.shaded.apache.avro.Schema.parse(Schema.java:1340)
>  at org.shaded.apache.avro.Schema.parse(Schema.java:1269)
>  at org.shaded.apache.avro.Schema$Parser.parse(Schema.java:1032)
>  at org.shaded.apache.avro.Schema$Parser.parse(Schema.java:1020)
> {code}



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

[jira] [Created] (AVRO-2173) remove CHANGES.txt

[Doug Cutting (JIRA)]

Doug Cutting created AVRO-2173:
--

 Summary: remove CHANGES.txt
 Key: AVRO-2173
 URL: https://issues.apache.org/jira/browse/AVRO-2173
 Project: Avro
  Issue Type: Improvement
Reporter: Doug Cutting


The CHANGES.txt file is not well maintained and redundant with information in 
Jira.

Let's remove this file, and instead generate release notes from Jira.



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

[jira] [Updated] (AVRO-2174) Enums with spaces are accepted

[Harshal Dalvi (JIRA)]

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

Harshal Dalvi updated AVRO-2174:

Description: The Avro spec does not allow for spaces *' '*  in enums. 
However, Python Avro does not error out or reject enums with spaces in them.  
(was: The Avro spec does not allow for spaces *' '*  in enums. However, Python 
Avro does not error out of reject enums with spaces in them.)

> Enums with spaces are accepted
> --
>
> Key: AVRO-2174
> URL: https://issues.apache.org/jira/browse/AVRO-2174
> Project: Avro
>  Issue Type: Bug
>  Components: python
>Affects Versions: 1.8.2
>Reporter: Harshal Dalvi
>Priority: Major
>
> The Avro spec does not allow for spaces *' '*  in enums. However, Python Avro 
> does not error out or reject enums with spaces in them.



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

Re: Giving credit for contributions through Github Pull Requests

[Gabor Szadovszky]

+1 for both

On Fri, May 4, 2018 at 9:54 AM, Nandor Kollar  wrote:

> +1 for both, especially for removing CHANGES.txt.
>
> On Thu, May 3, 2018 at 11:18 PM, Doug Cutting  wrote:
>
> > Maybe we should loosen the permissions on Avro's Jira so that any user
> can
> > assign an issue?  That would make things a bit simpler.  I doubt we'd see
> > much if any abuse.
> >
> > Also, it's probably time to remove CHANGES.txt and just use Jira to
> > generate release notes.  Agreed?
> >
> > Doug
> >
> > On Thu, Apr 26, 2018 at 11:51 AM Sean Busbey 
> wrote:
> >
> > > On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting 
> wrote:
> > >
> > > > So I guess this would be easier if we also said that contributions
> > would
> > > > only now be accepted via pull request.  Is that too onerous?  Instead
> > of
> > > > requiring everyone to have an Apache Jira account we require them to
> > > have a
> > > > GitHub account.
> > > >
> > > >
> > > I take it the github contributor summary doesn't work for emails that
> > > aren't associated with a github id?
> > >
> > > What about jumping on the Apache Kibble train? They're trying to make
> > > similar "project observability" widgets as what github provides.
> > >
> > >
> > >
> > > > Moving issue tracking to GitHub seems unlikely, as it's lacking a lot
> > of
> > > > features we depend on from Jira.
> > > >
> > > >
> > > I don't like the idea of moving from JIRA to GitHub issues, but I think
> > GHI
> > > has all the features we'd need to do so, FYI. Or atleast, I can't think
> > of
> > > any we use that don't have a mapping to something.
> > >
> > >
> > > --
> > > busbey
> > >
> >
>

[jira] [Commented] (AVRO-2079) Add ability to use Java 8 date/time types instead of Joda time.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AVRO-2079:
--

pvorb opened a new pull request #309: AVRO-2079: Add ability to generate Java8 
native date/time classes (new)
URL: https://github.com/apache/avro/pull/309
 
 
   As there was no progress on #248 for the past few months, I went ahead and 
resolved the merge conflicts of that PR and also fixed the remarks from 
@Kuroshii.
   
   Here's a brief overview of what I've changed:
   
   - Reorder imports in TestJava8TimeConversions.java
   - Directly cast epochDays to int
   - Directly cast millis to int
   - Explicitly format java8 and joda time dates in test
   - Rename DateTimeLogicalTypeType to DateTimeLogicalTypeImplementation
   - Refactor registration of conversions
   - Make DateTimeLigicalTypeImplementation field final
   - Use parent POM version in Maven plugin tests
   - Log warning message about unknown parameter values
   - Remove unused imports
   
   I would also suggest to rename the enum value `JAVA8` and all of its uses to 
`JSR310` because that's more specific to the `java.time.*` APIs introduced in 
Java 8 (see https://jcp.org/en/jsr/detail?id=310). I can add that change if you 
agree.
   
   @Kuroshii I would appreciate if you could review this PR again, so maybe 
we'll have JSR-310 support in the next Avro release. Thanks!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Add ability to use Java 8 date/time types instead of Joda time.
> ---
>
> Key: AVRO-2079
> URL: https://issues.apache.org/jira/browse/AVRO-2079
> Project: Avro
>  Issue Type: Improvement
>  Components: java, logical types
>Affects Versions: 1.8.2
>Reporter: Auke van Leeuwen
>Priority: Major
>  Labels: patch-available
>
> Currently, for the date/time related logical types, we are generating Joda 
> date/time objects. Since we've moved to Java-8 (AVRO-2043) it seems logical 
> to also provide the possibility to generate {{java.time.*}} date/time objects 
> instead of the Joda time variants.
> I propose to make this is a switch in {{SpecificCompiler.java}} which will 
> default to Joda (I think), but can be set to generate the Java 8 versions.
> (I'm currently trying to run through the code to see if I can make it work.)



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

[jira] [Commented] (AVRO-1810) GenericDatumWriter broken with Enum

[Adam Bellemare (JIRA)]

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

Adam Bellemare commented on AVRO-1810:
--

[~zolyfarkas] - How has the use of your branch been in the past months? I am 
interested in having this ticket revived as this is something that I will also 
be needing to do. Is there anything I could do to help?

> GenericDatumWriter broken with Enum
> ---
>
> Key: AVRO-1810
> URL: https://issues.apache.org/jira/browse/AVRO-1810
> Project: Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.8.0
>Reporter: Ryon Day
>Priority: Blocker
> Fix For: 1.9.0, 1.8.4
>
>
> {panel:title=Description|titleBGColor=#3FA|bgColor=#DDD}
> Using the GenericDatumWriter with either Generic OR SpecificRecord will break 
> if an Enum is present.
> {panel}
> {panel:title=Steps To Reproduce|titleBGColor=#8DB|bgColor=#DDD}
> I have been tracking Avro decoding oddities for a while.
> The tests for this issue can be found 
> [here|https://github.com/ryonday/avroDecodingHelp/blob/master/src/test/java/com/ryonday/test/Avro180EnumFail.java]
> {panel}
> {panel:title=Notes|titleBGColor=#3AF|bgColor=#DDD}
> Due to the debacle that is the Avro "UTF8" object, we have been avoiding it 
> by using the following scheme:
> * Write incoming records to a byte array using the GenericDatumWriter
> * Read back the byte array to our compiled Java domain objects using a 
> SpecificDatumWriter
> This worked great with Avro 1.7.7, and this is a binary-incompatable breaking 
> change with 1.8.0.
> This would appear to be caused by an addition in the 
> {{GenericDatumWriter:163-164}}:
> {code}
>   if (!data.isEnum(datum))
>   throw new AvroTypeException("Not an enum: "+datum);
> {code}
> {panel}



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

Re: Giving credit for contributions through Github Pull Requests

[Sean Busbey]

On Thu, May 3, 2018 at 4:18 PM, Doug Cutting  wrote:

> Maybe we should loosen the permissions on Avro's Jira so that any user can
> assign an issue?  That would make things a bit simpler.  I doubt we'd see
> much if any abuse.
>

locking down issue assigning happened ASF jira wide due to spammer abuse.
we could probably due with better documenting how folks gain the ability to
assign themselves issues.

I presume it's "email dev@avro and ask for the ability". At the very least
I've been granting it to anyone who asks.



>
> Also, it's probably time to remove CHANGES.txt and just use Jira to
> generate release notes.  Agreed?
>
>
Yeah that'd be great.  The Apache Yetus project makes a tool called Release
Doc Maker that will generate markdown for us.

http://yetus.apache.org/documentation/0.7.0/releasedocmaker/

It's  been working for the Hadoop project for ages. HBase has started
moving to it and it's gone well.

-- 
busbey

Re: Giving credit for contributions through Github Pull Requests

[Nandor Kollar]

+1 for both, especially for removing CHANGES.txt.

On Thu, May 3, 2018 at 11:18 PM, Doug Cutting  wrote:

> Maybe we should loosen the permissions on Avro's Jira so that any user can
> assign an issue?  That would make things a bit simpler.  I doubt we'd see
> much if any abuse.
>
> Also, it's probably time to remove CHANGES.txt and just use Jira to
> generate release notes.  Agreed?
>
> Doug
>
> On Thu, Apr 26, 2018 at 11:51 AM Sean Busbey  wrote:
>
> > On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting  wrote:
> >
> > > So I guess this would be easier if we also said that contributions
> would
> > > only now be accepted via pull request.  Is that too onerous?  Instead
> of
> > > requiring everyone to have an Apache Jira account we require them to
> > have a
> > > GitHub account.
> > >
> > >
> > I take it the github contributor summary doesn't work for emails that
> > aren't associated with a github id?
> >
> > What about jumping on the Apache Kibble train? They're trying to make
> > similar "project observability" widgets as what github provides.
> >
> >
> >
> > > Moving issue tracking to GitHub seems unlikely, as it's lacking a lot
> of
> > > features we depend on from Jira.
> > >
> > >
> > I don't like the idea of moving from JIRA to GitHub issues, but I think
> GHI
> > has all the features we'd need to do so, FYI. Or atleast, I can't think
> of
> > any we use that don't have a mapping to something.
> >
> >
> > --
> > busbey
> >
>