[jira] [Updated] (AVRO-2888) Csharp - Specific reader fails when using c# keyword in namespace name

2020-07-09 Thread Vaibhav (Jira) 


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

Vaibhav updated AVRO-2888:
--
Description: 
 Csharp specific reader fails when csharp language keyword is present in 
namespace and datatype for on one of the element is array of complex type.

 Steps to reproduce - Use following schema file to generate avro csharp classes 
using Apache.Avro.Tools tool (v 1.10.0)
{code:java}
{
  "name": "Parent",
  "type": "record",
  "namespace": "com.parent.event",
  "fields": [
{
  "name": "children",
  "type": {
"type": "array",
"items": {
  "name": "Child",
  "type": "record",
  "fields": [
{
  "name": "name",
  "type": "string"
}
  ]
}
  }
}
  ]
}
{code}
Following classes will be generated. I have added link to files as content is 
relatively large.

[https://github.com/vkhose/testcode/blob/master/com/parent/event/Parent.cs]

[https://github.com/vkhose/testcode/blob/master/com/parent/event/Child.cs]

Please note that Avro generator tool adds an escape character "@" in namespace 
as event is a csharp keyword 

e.g. namespace com.parent.@event

Next, I have created a test case which tries to deserialize the Parent class 
object

[https://github.com/vkhose/testcode/blob/master/testCaseToReproduceError.cs]

 
{code:java}
 [Test]
 public void TestNamespaceWithCSharpKeyword()
 {
var srcRecord = new Parent
{
children = new List
{
new Child
{
name = "test"
},
new Child
{
name = "test"
}
}
};
var stream = serialize(Parent._SCHEMA, srcRecord);
var dstRecord = deserialize(stream,
Parent._SCHEMA, Parent._SCHEMA);
Assert.NotNull(dstRecord);
}
}{code}
 This test case throws following exception 

Unable to find type 'com.parent.@event.Child' in all loaded assemblies in field 
children
 > Avro.AvroException : Unable to find type 'com.parent.@event.Child' in 
all loaded assemblies
 at Avro.Specific.SpecificDefaultReader.ReadRecord(Object reuse, RecordSchema 
writerSchema, Schema readerSchema, Decoder dec)

 

When I debug the code it seems like same util methods are used to generate code 
for specific record and read record during deserialization.
 
[https://github.com/apache/avro/blob/c0094b5bb1abb79304ce42a56cc115186370d407/lang/csharp/src/apache/main/CodeGen/CodeGenUtil.cs#L99]
{code:java}
if (ReservedKeywords.Contains(names[i]))
   builder.Append(At);
{code}
Appending At(@) while generating code is correct but it should not appended 
while deserializing. Deserialization fails as c# reflection does not expects 
At(@) in string value provided to create class instance.
 
[https://github.com/apache/avro/blob/master/lang/csharp/src/apache/main/Specific/ObjectCreator.cs#L165]

Type.GetType(string) string parameter passed should be without "@" character in 
namespace name.

 

It works if I modify code not to add "@" in CodeGenUtil.cs. I think we need a 
fix where "@" is only added while auto generating classes and should not be 
used during deserialization.

Thanks.

Vaibhav

  was:
 Csharp specific reader fails when csharp language keyword is present in 
namespace and datatype for on one of the element is array of complex type.

 Steps to reproduce - Use following schema file to generate avro csharp classes 
using Apache.Avro.Tools tool (v 1.10.0)
{code:java}
{
  "name": "Parent",
  "type": "record",
  "namespace": "com.parent.event",
  "fields": [
{
  "name": "children",
  "type": {
"type": "array",
"items": {
  "name": "Child",
  "type": "record",
  "fields": [
{
  "name": "name",
  "type": "string"
}
  ]
}
  }
}
  ]
}
{code}
Following classes will be generated

[Parent.cs|[https://github.com/vkhose/testcode/blob/master/com/parent/event/Parent.cs]]

[Child.cs|[https://github.com/vkhose/testcode/blob/master/com/parent/event/Child.cs]]



Please note that Avro generator tool adds an escape character "@" in namespace 
as event is a csharp keyword 

e.g. namespace com.parent.@event

Next, I have created a test case which tries to deserialize the Parent class 
object

[Test case 
code|[https://github.com/vkhose/testcode/blob/master/testCaseToReproduceError.cs]]

 
{code:java}
 [Test]
 public void TestNamespaceWithCSharpKeyword()
 {
var srcRecord = new Parent
{
children = new List
{
new Child
{
name = "test"

[jira] [Created] (AVRO-2888) Csharp - Specific reader fails when using c# keyword in namespace name

2020-07-09 Thread Vaibhav (Jira) 
Vaibhav created AVRO-2888:
-

 Summary: Csharp - Specific reader fails when using c# keyword in 
namespace name
 Key: AVRO-2888
 URL: https://issues.apache.org/jira/browse/AVRO-2888
 Project: Apache Avro
  Issue Type: Bug
  Components: csharp
Affects Versions: 1.9.2
Reporter: Vaibhav


 Csharp specific reader fails when csharp language keyword is present in 
namespace and datatype for on one of the element is array of complex type.

 Steps to reproduce - Use following schema file to generate avro csharp classes 
using Apache.Avro.Tools tool (v 1.10.0)
{code:java}
{
  "name": "Parent",
  "type": "record",
  "namespace": "com.parent.event",
  "fields": [
{
  "name": "children",
  "type": {
"type": "array",
"items": {
  "name": "Child",
  "type": "record",
  "fields": [
{
  "name": "name",
  "type": "string"
}
  ]
}
  }
}
  ]
}
{code}
Following classes will be generated

[Parent.cs|[https://github.com/vkhose/testcode/blob/master/com/parent/event/Parent.cs]]

[Child.cs|[https://github.com/vkhose/testcode/blob/master/com/parent/event/Child.cs]]



Please note that Avro generator tool adds an escape character "@" in namespace 
as event is a csharp keyword 

e.g. namespace com.parent.@event

Next, I have created a test case which tries to deserialize the Parent class 
object

[Test case 
code|[https://github.com/vkhose/testcode/blob/master/testCaseToReproduceError.cs]]

 
{code:java}
 [Test]
 public void TestNamespaceWithCSharpKeyword()
 {
var srcRecord = new Parent
{
children = new List
{
new Child
{
name = "test"
},
new Child
{
name = "test"
}
}
};
var stream = serialize(Parent._SCHEMA, srcRecord);
var dstRecord = deserialize(stream,
Parent._SCHEMA, Parent._SCHEMA);
Assert.NotNull(dstRecord);
}
}{code}
 This test case throws following exception 

Unable to find type 'com.parent.@event.Child' in all loaded assemblies in field 
children
 > Avro.AvroException : Unable to find type 'com.parent.@event.Child' in 
all loaded assemblies
 at Avro.Specific.SpecificDefaultReader.ReadRecord(Object reuse, RecordSchema 
writerSchema, Schema readerSchema, Decoder dec)

 

When I debug the code it seems like same util methods are used to generate code 
for specific record and read record during deserialization.
[https://github.com/apache/avro/blob/c0094b5bb1abb79304ce42a56cc115186370d407/lang/csharp/src/apache/main/CodeGen/CodeGenUtil.cs#L99]
{code:java}
if (ReservedKeywords.Contains(names[i]))
   builder.Append(At);
{code}
Appending At(@) while generating code is correct but it should not appended 
while deserializing. Deserialization fails as c# reflection does not expects 
At(@) in string value provided to create class instance.
[https://github.com/apache/avro/blob/master/lang/csharp/src/apache/main/Specific/ObjectCreator.cs#L165]

Type.GetType(string) string parameter passed should be without "@" character in 
namespace name.

 

It works if I modify code not to add "@" in CodeGenUtil.cs. I think we need a 
fix where "@" is only added while auto generating classes and should not be 
used during deserialization.

Thanks.

Vaibhav



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2887) R binding for Avro

2020-07-09 Thread Dawn Lenz (Jira) 


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

Dawn Lenz updated AVRO-2887:

Description: 
Access Avro functionality from R

Patch implements binding to Avro C

  was:Access Avro functionality from R


> R binding for Avro
> --
>
> Key: AVRO-2887
> URL: https://issues.apache.org/jira/browse/AVRO-2887
> Project: Apache Avro
>  Issue Type: New Feature
>Reporter: Dawn Lenz
>Priority: Major
> Attachments: AVRO-2887.patch
>
>
> Access Avro functionality from R
> Patch implements binding to Avro C



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2887) R binding for Avro

2020-07-09 Thread Dawn Lenz (Jira) 


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

Dawn Lenz updated AVRO-2887:

Attachment: AVRO-2887.patch

> R binding for Avro
> --
>
> Key: AVRO-2887
> URL: https://issues.apache.org/jira/browse/AVRO-2887
> Project: Apache Avro
>  Issue Type: New Feature
>Reporter: Dawn Lenz
>Priority: Major
> Attachments: AVRO-2887.patch
>
>
> Access Avro functionality from R



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (AVRO-2887) R binding for Avro

2020-07-09 Thread Dawn Lenz (Jira) 
Dawn Lenz created AVRO-2887:
---

 Summary: R binding for Avro
 Key: AVRO-2887
 URL: https://issues.apache.org/jira/browse/AVRO-2887
 Project: Apache Avro
  Issue Type: New Feature
Reporter: Dawn Lenz


Access Avro functionality from R



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [avro] rpbaltazar closed pull request #840: [AVRO-2677] Added decimal encoding and decoding logic

2020-07-09 Thread GitBox 


rpbaltazar closed pull request #840:
URL: https://github.com/apache/avro/pull/840


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

Re: supporting a "unit" field for avro schema

2020-07-09 Thread Erik Erlandson 
Ismaël Mejía pointed out that the AEP for this feature should be voted on,
which I'm in complete agreement with. How should this proceed?
Cheers, Erik



On Wed, Sep 18, 2019 at 3:30 PM Erik Erlandson  wrote:

>
> I drafted an AEP for unit metadata on schema:
>
> https://docs.google.com/document/d/1IeVAtf6YcAAn35D4jmFQJjPpEMgEu79wWVMW37KvNps/
>
>
> On Tue, Jul 16, 2019 at 1:35 PM Erik Erlandson 
> wrote:
>
>> Hi Ryan,
>> Those are all great questions. They're all issues I have ideas about but
>> I'd want Avro community input for as well. For that reason I answered them
>> all on AVRO-2474 
>> Cheers!
>> E
>>
>> On Tue, Jul 16, 2019 at 3:13 AM Ryan Skraba  wrote:
>>
>>> Hello!  I've been thinking about this and I generally like the idea of
>>> stronger types with units :D
>>>
>>> I have some questions about what you are thinking of when you say "first
>>> class concept" in Avro:
>>> - Would you expect a writer schema that wrote a Fahrenheit field and a
>>> reader schema that reads Celsius to interact transparently with generic
>>> data?
>>> - What about conversions that lose precision (i.e., if the above
>>> conversion
>>> was on an INT field)?
>>> - How much of "unit" support should be mandatory in the spec for cross
>>> language operation?  (a unit-aware Scala writer with a Fahrenheit field
>>> and
>>> a non-unit-aware reader with a Celsius field).
>>> - To what degree would a generic reader of Avro data be required to
>>> support
>>> quantity wrappers (i.e. how can we opt-in/opt-out cleanly from being
>>> unit-aware)?
>>>
>>> At scale, I'd be particularly keen to see the conversion detection
>>> (between
>>> two schemas / fields / quantities) take place once, and then the
>>> calculation reused for all of the subsequent datum passing through, but
>>> I'm
>>> not sure how that would work.
>>>
>>> We have some experience with passing a lot of client data through Avro,
>>> and
>>> we use generic data quite a bit -- I'd be tempted to think of "float
>>> (metres)" as a distinct type from "float (minutes)", but it would be a
>>> huge
>>> (but potentially interesting) change for the way we look at data.  That
>>> being said, as far as units go, we see a lot more unitless values
>>> (quantity
>>> of items, percents and other ratios, ratings).  The most frequent numeric
>>> values with units that we see are probably money or geolocation (in
>>> practice, already normalized to lat/long -- although I just learned about
>>> UTM!).  Surprisingly, there's not as much SI-type unit data as you might
>>> expect.
>>>
>>> I can definitely see the value of using a "unit" annotation in a
>>> generated
>>> specific record for a supported language -- as proven by your scala work!
>>> That might be an easy first target while working out what a first-class
>>> concept in the spec would entail.  I missed Berlin Buzzwords by a day,
>>> but
>>> enjoyed the video, thanks!
>>>
>>> Ryan
>>>
>>>
>>>
>>> On Tue, Jul 16, 2019 at 1:24 AM Erik Erlandson 
>>> wrote:
>>>
>>> > If I'm interpreting the situation correctly, there is an "Avro
>>> Enhancement
>>> > Proposal", but none have been filed in nearly a decade:
>>> >
>>> https://cwiki.apache.org/confluence/display/AVRO/Avro+Enhancement+Proposals
>>> >
>>> > As a start, I submitted a jira to track this idea:
>>> > https://issues.apache.org/jira/browse/AVRO-2474
>>> >
>>> >
>>> >
>>> > On Mon, Jul 8, 2019 at 10:42 AM Erik Erlandson 
>>> > wrote:
>>> >
>>> > >
>>> > > What should I do to move this forward? Does Avro have a PIP process?
>>> > >
>>> > >
>>> > > On Sat, Jun 29, 2019 at 3:26 PM Erik Erlandson 
>>> > > wrote:
>>> > >
>>> > >>
>>> > >> Regarding schema, my proposal for fingerprints would be that units
>>> are
>>> > >> fingerprinted based on their canonical form, as defined here
>>> > >> <
>>> >
>>> http://erikerlandson.github.io/blog/2019/05/03/algorithmic-unit-analysis/
>>> > >.
>>> > >> Any two unit expressions having the same canonical form (including
>>> the
>>> > >> corresponding coefficients) are exactly equivalent, and so their
>>> > >> fingerprints can be the same. Possibly the unit could be stored on
>>> the
>>> > >> schema in canonical form by convention, although canonical forms are
>>> > >> frequently not as intuitive to humans and so in that case the
>>> > documentation
>>> > >> value of the unit might be reduced for humans examining the schema.
>>> > >>
>>> > >> For schema evolution, a unit change such that the previous and new
>>> unit
>>> > >> are convertable (also defined as at the above link) would be well
>>> > defined,
>>> > >> and automatic transformation would just be the correct unit
>>> conversion
>>> > >> (e.g. seconds to milliseconds). If the unit changes to a
>>> non-convertable
>>> > >> unit (e.g. seconds to bytes) then no automatic transformation
>>> exists,
>>> > and
>>> > >> attempting to resolve the old and new schema would be an error. Note
>>> > that
>>> > >> establishing the conversion assumes tha

[jira] [Commented] (AVRO-2886) Support logical type

2020-07-09 Thread Dawn Lenz (Jira) 


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

Dawn Lenz commented on AVRO-2886:
-

There is an open PR for this: [https://github.com/apache/avro/pull/843]

> Support logical type
> 
>
> Key: AVRO-2886
> URL: https://issues.apache.org/jira/browse/AVRO-2886
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: c
>Affects Versions: 1.10.0
>Reporter: Dawn Lenz
>Priority: Major
>
> This is a request to add support for avro logical types.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (AVRO-2886) Support logical type

2020-07-09 Thread Dawn Lenz (Jira) 
Dawn Lenz created AVRO-2886:
---

 Summary: Support logical type
 Key: AVRO-2886
 URL: https://issues.apache.org/jira/browse/AVRO-2886
 Project: Apache Avro
  Issue Type: Improvement
  Components: c
Affects Versions: 1.10.0
Reporter: Dawn Lenz


This is a request to add support for avro logical types.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-2382) VERSION constant in Ruby gem returns FIXME

2020-07-09 Thread Hudson (Jira) 


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

Hudson commented on AVRO-2382:
--

SUCCESS: Integrated in Jenkins build AvroJava #914 (See 
[https://builds.apache.org/job/AvroJava/914/])
AVRO-2382: Fix VERSION constant for Ruby gem (#928) (github: 
[https://github.com/apache/avro/commit/dc2afc5d3bedefa0fa1dfe611adfaedd67418a51])
* (edit) lang/ruby/Manifest
* (edit) lang/ruby/lib/avro.rb
* (edit) lang/ruby/Rakefile
* (edit) lang/ruby/.gitignore


> VERSION constant in Ruby gem returns FIXME
> --
>
> Key: AVRO-2382
> URL: https://issues.apache.org/jira/browse/AVRO-2382
> Project: Apache Avro
>  Issue Type: Bug
>  Components: ruby
>Affects Versions: 1.8.2, 1.10.0, 1.9.1
>Reporter: Tim Perkins
>Assignee: Tim Perkins
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.11.0, 1.10.1
>
>
> The VERSION constant in the Ruby gem returns "FIXME". I've listed v1.8.2 as 
> the affected version as that (and 1.9.0 RC1) are the only versions that I 
> tested, but I suspect this issue goes back further:
>   558af6be6 (Douglass Cutting 2010-01-20 01:05:06 + 25)   VERSION = 
> "FIXME"
> This bug makes it difficult to determine the version of the Ruby gem at 
> runtime.
> I suspect this is something that should be replaced by the actual version 
> when the gem is packaged.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2382) VERSION constant in Ruby gem returns FIXME

2020-07-09 Thread Ryan Skraba (Jira) 


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

Ryan Skraba updated AVRO-2382:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks!  Merged to master and cherry-picked to branch-1.10 for the next major 
and minor releases.

> VERSION constant in Ruby gem returns FIXME
> --
>
> Key: AVRO-2382
> URL: https://issues.apache.org/jira/browse/AVRO-2382
> Project: Apache Avro
>  Issue Type: Bug
>  Components: ruby
>Affects Versions: 1.8.2, 1.10.0, 1.9.1
>Reporter: Tim Perkins
>Assignee: Tim Perkins
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.11.0, 1.10.1
>
>
> The VERSION constant in the Ruby gem returns "FIXME". I've listed v1.8.2 as 
> the affected version as that (and 1.9.0 RC1) are the only versions that I 
> tested, but I suspect this issue goes back further:
>   558af6be6 (Douglass Cutting 2010-01-20 01:05:06 + 25)   VERSION = 
> "FIXME"
> This bug makes it difficult to determine the version of the Ruby gem at 
> runtime.
> I suspect this is something that should be replaced by the actual version 
> when the gem is packaged.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-2382) VERSION constant in Ruby gem returns FIXME

2020-07-09 Thread ASF subversion and git services (Jira) 


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

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

Commit b8554aa8f9b917c39529b8bfe5264e092df8584e in avro's branch 
refs/heads/branch-1.10 from Tim Perkins
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=b8554aa ]

AVRO-2382: Fix VERSION constant for Ruby gem (#928)



> VERSION constant in Ruby gem returns FIXME
> --
>
> Key: AVRO-2382
> URL: https://issues.apache.org/jira/browse/AVRO-2382
> Project: Apache Avro
>  Issue Type: Bug
>  Components: ruby
>Affects Versions: 1.8.2, 1.10.0, 1.9.1
>Reporter: Tim Perkins
>Assignee: Tim Perkins
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.11.0, 1.10.1
>
>
> The VERSION constant in the Ruby gem returns "FIXME". I've listed v1.8.2 as 
> the affected version as that (and 1.9.0 RC1) are the only versions that I 
> tested, but I suspect this issue goes back further:
>   558af6be6 (Douglass Cutting 2010-01-20 01:05:06 + 25)   VERSION = 
> "FIXME"
> This bug makes it difficult to determine the version of the Ruby gem at 
> runtime.
> I suspect this is something that should be replaced by the actual version 
> when the gem is packaged.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-2382) VERSION constant in Ruby gem returns FIXME

2020-07-09 Thread ASF subversion and git services (Jira) 


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

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

Commit dc2afc5d3bedefa0fa1dfe611adfaedd67418a51 in avro's branch 
refs/heads/master from Tim Perkins
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=dc2afc5 ]

AVRO-2382: Fix VERSION constant for Ruby gem (#928)



> VERSION constant in Ruby gem returns FIXME
> --
>
> Key: AVRO-2382
> URL: https://issues.apache.org/jira/browse/AVRO-2382
> Project: Apache Avro
>  Issue Type: Bug
>  Components: ruby
>Affects Versions: 1.8.2, 1.10.0, 1.9.1
>Reporter: Tim Perkins
>Assignee: Tim Perkins
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.11.0, 1.10.1
>
>
> The VERSION constant in the Ruby gem returns "FIXME". I've listed v1.8.2 as 
> the affected version as that (and 1.9.0 RC1) are the only versions that I 
> tested, but I suspect this issue goes back further:
>   558af6be6 (Douglass Cutting 2010-01-20 01:05:06 + 25)   VERSION = 
> "FIXME"
> This bug makes it difficult to determine the version of the Ruby gem at 
> runtime.
> I suspect this is something that should be replaced by the actual version 
> when the gem is packaged.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [avro] RyanSkraba merged pull request #928: AVRO-2382: Fix VERSION constant for Ruby gem

2020-07-09 Thread GitBox 


RyanSkraba merged pull request #928:
URL: https://github.com/apache/avro/pull/928


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[jira] [Created] (AVRO-2885) It is possible to provide a number with decimal digits in an int field

2020-07-09 Thread Federico Ragona (Jira) 
Federico Ragona created AVRO-2885:
-

 Summary: It is possible to provide a number with decimal digits in 
an int field
 Key: AVRO-2885
 URL: https://issues.apache.org/jira/browse/AVRO-2885
 Project: Apache Avro
  Issue Type: Bug
  Components: java
Affects Versions: 1.8.2
Reporter: Federico Ragona


I defined a schema with an {{int}} field and I'm then using the Java 
{{GenericDatumReader}} to read records: I have noticed that the reader also 
accepts numbers with decimal digits and the resulting record contains the same 
numbers, coerced to integer values. I have observed the same behaviour both 
when decoding from JSON and from binary. Here is a runnable example:

{code:java}
import org.apache.avro.Schema;
import org.apache.avro.SchemaBuilder;
import org.apache.avro.generic.GenericDatumReader;
import org.apache.avro.generic.GenericRecord;
import org.apache.avro.io.Decoder;
import org.apache.avro.io.DecoderFactory;

public class AvroIntTest {

public static GenericRecord readFromJson(Schema schema, String record) 
throws Exception {
GenericDatumReader reader = new 
GenericDatumReader<>(schema, schema);
Decoder decoder = DecoderFactory.get().jsonDecoder(schema, record);
return reader.read(null, decoder);
}

public static void main(String[] args) throws Exception {
Schema schema = SchemaBuilder
.builder("test")
.record("example")
.fields()
.requiredInt("id")
.endRecord();
String record = "{ \"id\": -1.2 }";

System.out.println(readFromJson(schema, record)); // prints: { "id": -1 
}
}

}
{code}

The schema generated by the builder looks like this:

{code}
{
  "type" : "record",
  "name" : "example",
  "namespace" : "test",
  "fields" : [ {
"name" : "id",
"type" : "int"
  } ]
}
{code}

I would expect the reader to fail because the type of the value doesn't match 
the type of the field but it instead "silently" succeeds, converting {{-1.2}} 
to {{-1}}: is this behaviour intended? am I doing something wrong?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)