[jira] [Commented] (AVRO-2212) GenericData.deepCopyRaw not working with java.lang.BigDecimal
[
https://issues.apache.org/jira/browse/AVRO-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16585310#comment-16585310
]
Sean Policarpio commented on AVRO-2212:
---
Just realised in the original Scala version I didn't call {{build}} on {{x}}.
In any case, this causes the same error in the constructors at
{{SomethingWithDec.java:135}} and {{SomethingWithDec.java:144}}, using the
builder or the record to perform a deep copy.
> GenericData.deepCopyRaw not working with java.lang.BigDecimal
> -
>
> Key: AVRO-2212
> URL: https://issues.apache.org/jira/browse/AVRO-2212
> Project: Avro
> Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Sean Policarpio
>Priority: Critical
> Attachments: SomethingWithDec.java
>
>
> With an AVDL of:
> {code:java}
> @namespace("com.foo")
> record SomethingWithDec {
> decimal(8,2) dec;
> }
> {code}
> and the Scala/Java code of:
> {code}
> object Foo extends App {
> import com.foo.SomethingWithDec
> val x = SomethingWithDec.newBuilder().setDec(new
> java.math.BigDecimal("1234"))
> val y = SomethingWithDec.newBuilder(x).build()
> }
> {code}
> I get the exception:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException: java.math.BigDecimal
> cannot be cast to java.nio.ByteBuffer
> at
> org.apache.avro.generic.GenericData.deepCopyRaw(GenericData.java:1089)
> at org.apache.avro.generic.GenericData.deepCopy(GenericData.java:1065)
> at com.foo.SomethingWithDec$Builder.(SomethingWithDec.java:167)
> at com.foo.SomethingWithDec$Builder.(SomethingWithDec.java:150)
> at com.foo.SomethingWithDec.newBuilder(SomethingWithDec.java:135)
> {noformat}
> I have attached the generated Java class for {{SomethingWithDec.}}
> This seems related to AVRO-1895, but I believe that was meant to have been
> fixed in 1.8.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AVRO-2212) GenericData.deepCopyRaw not working with java.lang.BigDecimal
[
https://issues.apache.org/jira/browse/AVRO-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16585307#comment-16585307
]
Sean Policarpio commented on AVRO-2212:
---
Was also able to reproduce in Java:
{code:Java}
class Scratch {
public static void main(String[] args) {
SomethingWithDec x = SomethingWithDec.newBuilder().setDec(new
BigDecimal("1234")).build();
SomethingWithDec y = SomethingWithDec.newBuilder(x).build();
}
}
{code}
{noformat}
Exception in thread "main" java.lang.ClassCastException: java.math.BigDecimal
cannot be cast to java.nio.ByteBuffer
at org.apache.avro.generic.GenericData.deepCopyRaw(GenericData.java:1089)
at org.apache.avro.generic.GenericData.deepCopy(GenericData.java:1065)
at com.foo.SomethingWithDec$Builder.(SomethingWithDec.java:179)
at com.foo.SomethingWithDec$Builder.(SomethingWithDec.java:150)
at com.foo.SomethingWithDec.newBuilder(SomethingWithDec.java:144)
{noformat}
> GenericData.deepCopyRaw not working with java.lang.BigDecimal
> -
>
> Key: AVRO-2212
> URL: https://issues.apache.org/jira/browse/AVRO-2212
> Project: Avro
> Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Sean Policarpio
>Priority: Critical
> Attachments: SomethingWithDec.java
>
>
> With an AVDL of:
> {code:java}
> @namespace("com.foo")
> record SomethingWithDec {
> decimal(8,2) dec;
> }
> {code}
> and the Scala/Java code of:
> {code}
> object Foo extends App {
> import com.foo.SomethingWithDec
> val x = SomethingWithDec.newBuilder().setDec(new
> java.math.BigDecimal("1234"))
> val y = SomethingWithDec.newBuilder(x).build()
> }
> {code}
> I get the exception:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException: java.math.BigDecimal
> cannot be cast to java.nio.ByteBuffer
> at
> org.apache.avro.generic.GenericData.deepCopyRaw(GenericData.java:1089)
> at org.apache.avro.generic.GenericData.deepCopy(GenericData.java:1065)
> at com.foo.SomethingWithDec$Builder.(SomethingWithDec.java:167)
> at com.foo.SomethingWithDec$Builder.(SomethingWithDec.java:150)
> at com.foo.SomethingWithDec.newBuilder(SomethingWithDec.java:135)
> {noformat}
> I have attached the generated Java class for {{SomethingWithDec.}}
> This seems related to AVRO-1895, but I believe that was meant to have been
> fixed in 1.8.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AVRO-2212) GenericData.deepCopyRaw not working with java.lang.BigDecimal
Sean Policarpio created AVRO-2212:
-
Summary: GenericData.deepCopyRaw not working with
java.lang.BigDecimal
Key: AVRO-2212
URL: https://issues.apache.org/jira/browse/AVRO-2212
Project: Avro
Issue Type: Bug
Affects Versions: 1.8.2
Reporter: Sean Policarpio
Attachments: SomethingWithDec.java
With an AVDL of:
{code:java}
@namespace("com.foo")
record SomethingWithDec {
decimal(8,2) dec;
}
{code}
and the Scala/Java code of:
{code}
object Foo extends App {
import com.foo.SomethingWithDec
val x = SomethingWithDec.newBuilder().setDec(new
java.math.BigDecimal("1234"))
val y = SomethingWithDec.newBuilder(x).build()
}
{code}
I get the exception:
{noformat}
Exception in thread "main" java.lang.ClassCastException: java.math.BigDecimal
cannot be cast to java.nio.ByteBuffer
at
org.apache.avro.generic.GenericData.deepCopyRaw(GenericData.java:1089)
at org.apache.avro.generic.GenericData.deepCopy(GenericData.java:1065)
at com.foo.SomethingWithDec$Builder.(SomethingWithDec.java:167)
at com.foo.SomethingWithDec$Builder.(SomethingWithDec.java:150)
at com.foo.SomethingWithDec.newBuilder(SomethingWithDec.java:135)
{noformat}
I have attached the generated Java class for {{SomethingWithDec.}}
This seems related to AVRO-1895, but I believe that was meant to have been
fixed in 1.8.2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AVRO-2132) Avro IDL: Support dot ('.') character in property annotation names
[
https://issues.apache.org/jira/browse/AVRO-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373572#comment-16373572
]
Sean Policarpio edited comment on AVRO-2132 at 2/22/18 10:24 PM:
-
[~zolyfarkas] [~cutting]
If I'm understanding this correctly, 1.9.0 will enforce default values? If so,
I can append defaults for both my new fields {{l}} and {{nested_properties}}
({{0}} and {{null}} respectively). However, shouldn't the enum field {{kind}}
also specified a default?
was (Author: kdrakon):
[~zolyfarkas] [~cutting]
If I'm understanding this correctly, 1.9.0 will enforce default values? If so,
I can append defaults for both my new fields `l` and `nested_properties` (`0`
and `null` respectively). However, shouldn't the enum field `kind` also
specified a default?
> Avro IDL: Support dot ('.') character in property annotation names
> --
>
> Key: AVRO-2132
> URL: https://issues.apache.org/jira/browse/AVRO-2132
> Project: Avro
> Issue Type: Improvement
> Components: java
>Affects Versions: 1.8.2
>Reporter: Sean Policarpio
>Assignee: Doug Cutting
>Priority: Major
> Fix For: 1.9.0
>
>
> Unless there is a strong reason why names like {{@foo.bar}} can't be used as
> property annotations in IDL, I propose an enhancement to the IDL parser to
> allow it.
> The major drive for this change comes from Kafka Connect; for a certain
> fields – namely timestamps – additional metadata must be present in the
> schema when certain consumers read the data (e.g. [the JDBC
> connector|https://github.com/confluentinc/kafka-connect-jdbc]). What I hoped
> when using IDL was to write the following for a record field:
> {code:java}
> union {null, @connect.version(1)
> @connect.name("org.apache.kafka.connect.data.Timestamp") long}
> queryTime;{code}
> so that the following would be available in the schemata:
> {code:java}
> {
> "name": "queryTime",
> "type": [
> "null",
> {
> "type": "long",
> "connect.version": 1,
> "connect.name": "org.apache.kafka.connect.data.Timestamp"
> }
> ],
> "default": null
> }{code}
> Unfortunately, both {{connect.version}} and {{connect.name}} are unacceptable
> by the parser.
> The change for this is quite minimal as it can be based on AVRO-1267.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AVRO-2132) Avro IDL: Support dot ('.') character in property annotation names
[
https://issues.apache.org/jira/browse/AVRO-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373572#comment-16373572
]
Sean Policarpio commented on AVRO-2132:
---
[~zolyfarkas] [~cutting]
If I'm understanding this correctly, 1.9.0 will enforce default values? If so,
I can append defaults for both my new fields `l` and `nested_properties` (`0`
and `null` respectively). However, shouldn't the enum field `kind` also
specified a default?
> Avro IDL: Support dot ('.') character in property annotation names
> --
>
> Key: AVRO-2132
> URL: https://issues.apache.org/jira/browse/AVRO-2132
> Project: Avro
> Issue Type: Improvement
> Components: java
>Affects Versions: 1.8.2
>Reporter: Sean Policarpio
>Assignee: Doug Cutting
>Priority: Major
> Fix For: 1.9.0
>
>
> Unless there is a strong reason why names like {{@foo.bar}} can't be used as
> property annotations in IDL, I propose an enhancement to the IDL parser to
> allow it.
> The major drive for this change comes from Kafka Connect; for a certain
> fields – namely timestamps – additional metadata must be present in the
> schema when certain consumers read the data (e.g. [the JDBC
> connector|https://github.com/confluentinc/kafka-connect-jdbc]). What I hoped
> when using IDL was to write the following for a record field:
> {code:java}
> union {null, @connect.version(1)
> @connect.name("org.apache.kafka.connect.data.Timestamp") long}
> queryTime;{code}
> so that the following would be available in the schemata:
> {code:java}
> {
> "name": "queryTime",
> "type": [
> "null",
> {
> "type": "long",
> "connect.version": 1,
> "connect.name": "org.apache.kafka.connect.data.Timestamp"
> }
> ],
> "default": null
> }{code}
> Unfortunately, both {{connect.version}} and {{connect.name}} are unacceptable
> by the parser.
> The change for this is quite minimal as it can be based on AVRO-1267.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AVRO-2132) Avro IDL: Support dot ('.') character in property annotation names
[
https://issues.apache.org/jira/browse/AVRO-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347694#comment-16347694
]
Sean Policarpio commented on AVRO-2132:
---
Hello, anyone able to quickly review this?
> Avro IDL: Support dot ('.') character in property annotation names
> --
>
> Key: AVRO-2132
> URL: https://issues.apache.org/jira/browse/AVRO-2132
> Project: Avro
> Issue Type: Improvement
> Components: java
>Affects Versions: 1.8.2
>Reporter: Sean Policarpio
>Priority: Major
>
> Unless there is a strong reason why names like {{@foo.bar}} can't be used as
> property annotations in IDL, I propose an enhancement to the IDL parser to
> allow it.
> The major drive for this change comes from Kafka Connect; for a certain
> fields – namely timestamps – additional metadata must be present in the
> schema when certain consumers read the data (e.g. [the JDBC
> connector|https://github.com/confluentinc/kafka-connect-jdbc]). What I hoped
> when using IDL was to write the following for a record field:
> {code:java}
> union {null, @connect.version(1)
> @connect.name("org.apache.kafka.connect.data.Timestamp") long}
> queryTime;{code}
> so that the following would be available in the schemata:
> {code:java}
> {
> "name": "queryTime",
> "type": [
> "null",
> {
> "type": "long",
> "connect.version": 1,
> "connect.name": "org.apache.kafka.connect.data.Timestamp"
> }
> ],
> "default": null
> }{code}
> Unfortunately, both {{connect.version}} and {{connect.name}} are unacceptable
> by the parser.
> The change for this is quite minimal as it can be based on AVRO-1267.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AVRO-2132) Avro IDL: Support dot ('.') character in property annotation names
[
https://issues.apache.org/jira/browse/AVRO-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Policarpio updated AVRO-2132:
--
Description:
Unless there is a strong reason why names like {{@foo.bar}} can't be used as
property annotations in IDL, I propose an enhancement to the IDL parser to
allow it.
The major drive for this change comes from Kafka Connect; for a certain fields
– namely timestamps – additional metadata must be present in the schema when
certain consumers read the data (e.g. [the JDBC
connector|https://github.com/confluentinc/kafka-connect-jdbc]). What I hoped
when using IDL was to write the following for a record field:
{code:java}
union {null, @connect.version(1)
@connect.name("org.apache.kafka.connect.data.Timestamp") long} queryTime;{code}
so that the following would be available in the schemata:
{code:java}
{
"name": "queryTime",
"type": [
"null",
{
"type": "long",
"connect.version": 1,
"connect.name": "org.apache.kafka.connect.data.Timestamp"
}
],
"default": null
}{code}
Unfortunately, both {{connect.version}} and {{connect.name}} are unacceptable
by the parser.
The change for this is quite minimal as it can be based on AVRO-1267.
was:
Unless there is a strong reason why names like @foo.bar can't be used as
property annotations in IDL, I propose an enhancement to the IDL parser to
allow it.
The major drive for this change comes from Kafka Connect; for a certain fields
– namely timestamps – additional metadata must be present in the schema when
certain consumers read the data (e.g. [the JDBC
connector|https://github.com/confluentinc/kafka-connect-jdbc]). What I hoped
when using IDL was to write the following for a record field:
{code:java}
union {null, @connect.version(1)
@connect.name("org.apache.kafka.connect.data.Timestamp") long} queryTime;{code}
so that the following would be available in the schemata:
{code:java}
{
"name": "queryTime",
"type": [
"null",
{
"type": "long",
"connect.version": 1,
"connect.name": "org.apache.kafka.connect.data.Timestamp"
}
],
"default": null
}{code}
Unfortunately, both connect.version and connect.name are unacceptable by the
parser.
The change for this is quite minimal as it can be based on AVRO-1267.
> Avro IDL: Support dot ('.') character in property annotation names
> --
>
> Key: AVRO-2132
> URL: https://issues.apache.org/jira/browse/AVRO-2132
> Project: Avro
> Issue Type: Improvement
> Components: java
>Affects Versions: 1.8.2
>Reporter: Sean Policarpio
>Priority: Major
>
> Unless there is a strong reason why names like {{@foo.bar}} can't be used as
> property annotations in IDL, I propose an enhancement to the IDL parser to
> allow it.
> The major drive for this change comes from Kafka Connect; for a certain
> fields – namely timestamps – additional metadata must be present in the
> schema when certain consumers read the data (e.g. [the JDBC
> connector|https://github.com/confluentinc/kafka-connect-jdbc]). What I hoped
> when using IDL was to write the following for a record field:
> {code:java}
> union {null, @connect.version(1)
> @connect.name("org.apache.kafka.connect.data.Timestamp") long}
> queryTime;{code}
> so that the following would be available in the schemata:
> {code:java}
> {
> "name": "queryTime",
> "type": [
> "null",
> {
> "type": "long",
> "connect.version": 1,
> "connect.name": "org.apache.kafka.connect.data.Timestamp"
> }
> ],
> "default": null
> }{code}
> Unfortunately, both {{connect.version}} and {{connect.name}} are unacceptable
> by the parser.
> The change for this is quite minimal as it can be based on AVRO-1267.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AVRO-2132) Avro IDL: Support dot ('.') character in property annotation names
Sean Policarpio created AVRO-2132:
-
Summary: Avro IDL: Support dot ('.') character in property
annotation names
Key: AVRO-2132
URL: https://issues.apache.org/jira/browse/AVRO-2132
Project: Avro
Issue Type: Improvement
Components: java
Affects Versions: 1.8.2
Reporter: Sean Policarpio
Unless there is a strong reason why names like @foo.bar can't be used as
property annotations in IDL, I propose an enhancement to the IDL parser to
allow it.
The major drive for this change comes from Kafka Connect; for a certain fields
– namely timestamps – additional metadata must be present in the schema when
certain consumers read the data (e.g. [the JDBC
connector|https://github.com/confluentinc/kafka-connect-jdbc]). What I hoped
when using IDL was to write the following for a record field:
{code:java}
union {null, @connect.version(1)
@connect.name("org.apache.kafka.connect.data.Timestamp") long} queryTime;{code}
so that the following would be available in the schemata:
{code:java}
{
"name": "queryTime",
"type": [
"null",
{
"type": "long",
"connect.version": 1,
"connect.name": "org.apache.kafka.connect.data.Timestamp"
}
],
"default": null
}{code}
Unfortunately, both connect.version and connect.name are unacceptable by the
parser.
The change for this is quite minimal as it can be based on AVRO-1267.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
