[jira] [Commented] (AVRO-1754) C++ ValiditingDecoder handles null incorrectly
[
https://issues.apache.org/jira/browse/AVRO-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029212#comment-15029212
]
Hudson commented on AVRO-1754:
--
SUCCESS: Integrated in AvroJava #552 (See
[https://builds.apache.org/job/AvroJava/552/])
AVRO-1754. C++ ValiditingDecoder handles null incorrectly (thiru: rev 1716757)
* trunk/CHANGES.txt
* trunk/lang/c++/impl/parsing/ValidatingCodec.cc
> C++ ValiditingDecoder handles null incorrectly
> --
>
> Key: AVRO-1754
> URL: https://issues.apache.org/jira/browse/AVRO-1754
> Project: Avro
> Issue Type: Bug
> Components: c++
>Reporter: John McClean
>Assignee: John McClean
> Fix For: 1.8.0
>
> Attachments: AVRO-1754.patch
>
>
> When decoding null, the ValidatingDecoder does not call the underlying
> 'decodeNull' method. The result is that the next field decoded causes an
> exception.
> For example, if this json
> {quote}
> \{"a":null,"b":"bar"}
> {quote}
> is decoded with this schema
> {quote}
> \{
> "name": "foo",
> "type": "record",
> "fields": [
> \{ "name": "a", "type": ["null", "string"] },
> \{ "name": "b", "type": "string" }
> ]
> }
> {quote}
> it throws an exception with the message "Invalid operation. Expected: String
> got Null". This happens when 'b' is being decoded. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (AVRO-1750) GenericDatum API behavior breaking change
[
https://issues.apache.org/jira/browse/AVRO-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. reopened AVRO-1750:
---
Assignee: (was: John McClean)
> GenericDatum API behavior breaking change
> -
>
> Key: AVRO-1750
> URL: https://issues.apache.org/jira/browse/AVRO-1750
> Project: Avro
> Issue Type: Bug
> Components: c++
>Affects Versions: 1.7.7
>Reporter: Braden McDaniel
> Fix For: 1.8.0
>
>
> It appears that a change was introduced to the {{avro::GenericDatum}}
> implementation between 1.7.6 and 1.7.7 that causes unions to be handled
> differently.
> The 1.7.6 implementation does this:
> {noformat}
> inline Type AVRO_DECL GenericDatum::type() const {
> return (type_ == AVRO_UNION) ?
> boost::any_cast(&value_)->type() : type_;
> }
> template
> const T& GenericDatum::value() const {
> return (type_ == AVRO_UNION) ?
> boost::any_cast(&value_)->value() :
> *boost::any_cast(&value_);
> }
> template
> T& GenericDatum::value() {
> return (type_ == AVRO_UNION) ?
> boost::any_cast(&value_)->value() :
> *boost::any_cast(&value_);
> }
> {noformat}
> …whereas the 1.7.7 implementation does this:
> {noformat}
> /**
> * The avro data type this datum holds.
> */
> Type type() const {
> return type_;
> }
> /**
> * Returns the value held by this datum.
> * T The type for the value. This must correspond to the
> * avro type returned by type().
> */
> template const T& value() const {
> return *boost::any_cast(&value_);
> }
> /**
> * Returns the reference to the value held by this datum, which
> * can be used to change the contents. Please note that only
> * value can be changed, the data type of the value held cannot
> * be changed.
> *
> * T The type for the value. This must correspond to the
> * avro type returned by type().
> */
> template T& value() {
> return *boost::any_cast(&value_);
> }
> {noformat}
> The result of this is that, if the underlying value is an {{AVRO_UNION}},
> calls to {{GenericDatum::type}} and {{GenericDatum::value<>}} that previously
> resolved to the union member type no longer do so (and user code relying on
> that behavior has been broken).
> This change apparently was made as part of the changes for AVRO-1474;
> however, looking at the comments in that issue, it's not clear to me why it
> was required for that fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AVRO-1754) C++ ValiditingDecoder handles null incorrectly
[
https://issues.apache.org/jira/browse/AVRO-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. updated AVRO-1754:
--
Assignee: John McClean
> C++ ValiditingDecoder handles null incorrectly
> --
>
> Key: AVRO-1754
> URL: https://issues.apache.org/jira/browse/AVRO-1754
> Project: Avro
> Issue Type: Bug
> Components: c++
>Reporter: John McClean
>Assignee: John McClean
> Fix For: 1.8.0
>
> Attachments: AVRO-1754.patch
>
>
> When decoding null, the ValidatingDecoder does not call the underlying
> 'decodeNull' method. The result is that the next field decoded causes an
> exception.
> For example, if this json
> {quote}
> \{"a":null,"b":"bar"}
> {quote}
> is decoded with this schema
> {quote}
> \{
> "name": "foo",
> "type": "record",
> "fields": [
> \{ "name": "a", "type": ["null", "string"] },
> \{ "name": "b", "type": "string" }
> ]
> }
> {quote}
> it throws an exception with the message "Invalid operation. Expected: String
> got Null". This happens when 'b' is being decoded. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AVRO-1754) C++ ValiditingDecoder handles null incorrectly
[
https://issues.apache.org/jira/browse/AVRO-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. updated AVRO-1754:
--
Resolution: Fixed
Fix Version/s: 1.8.0
Status: Resolved (was: Patch Available)
> C++ ValiditingDecoder handles null incorrectly
> --
>
> Key: AVRO-1754
> URL: https://issues.apache.org/jira/browse/AVRO-1754
> Project: Avro
> Issue Type: Bug
> Components: c++
>Reporter: John McClean
>Assignee: John McClean
> Fix For: 1.8.0
>
> Attachments: AVRO-1754.patch
>
>
> When decoding null, the ValidatingDecoder does not call the underlying
> 'decodeNull' method. The result is that the next field decoded causes an
> exception.
> For example, if this json
> {quote}
> \{"a":null,"b":"bar"}
> {quote}
> is decoded with this schema
> {quote}
> \{
> "name": "foo",
> "type": "record",
> "fields": [
> \{ "name": "a", "type": ["null", "string"] },
> \{ "name": "b", "type": "string" }
> ]
> }
> {quote}
> it throws an exception with the message "Invalid operation. Expected: String
> got Null". This happens when 'b' is being decoded. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AVRO-1750) GenericDatum API behavior breaking change
[
https://issues.apache.org/jira/browse/AVRO-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. resolved AVRO-1750.
---
Resolution: Fixed
Fix Version/s: 1.8.0
> GenericDatum API behavior breaking change
> -
>
> Key: AVRO-1750
> URL: https://issues.apache.org/jira/browse/AVRO-1750
> Project: Avro
> Issue Type: Bug
> Components: c++
>Affects Versions: 1.7.7
>Reporter: Braden McDaniel
>Assignee: John McClean
> Fix For: 1.8.0
>
>
> It appears that a change was introduced to the {{avro::GenericDatum}}
> implementation between 1.7.6 and 1.7.7 that causes unions to be handled
> differently.
> The 1.7.6 implementation does this:
> {noformat}
> inline Type AVRO_DECL GenericDatum::type() const {
> return (type_ == AVRO_UNION) ?
> boost::any_cast(&value_)->type() : type_;
> }
> template
> const T& GenericDatum::value() const {
> return (type_ == AVRO_UNION) ?
> boost::any_cast(&value_)->value() :
> *boost::any_cast(&value_);
> }
> template
> T& GenericDatum::value() {
> return (type_ == AVRO_UNION) ?
> boost::any_cast(&value_)->value() :
> *boost::any_cast(&value_);
> }
> {noformat}
> …whereas the 1.7.7 implementation does this:
> {noformat}
> /**
> * The avro data type this datum holds.
> */
> Type type() const {
> return type_;
> }
> /**
> * Returns the value held by this datum.
> * T The type for the value. This must correspond to the
> * avro type returned by type().
> */
> template const T& value() const {
> return *boost::any_cast(&value_);
> }
> /**
> * Returns the reference to the value held by this datum, which
> * can be used to change the contents. Please note that only
> * value can be changed, the data type of the value held cannot
> * be changed.
> *
> * T The type for the value. This must correspond to the
> * avro type returned by type().
> */
> template T& value() {
> return *boost::any_cast(&value_);
> }
> {noformat}
> The result of this is that, if the underlying value is an {{AVRO_UNION}},
> calls to {{GenericDatum::type}} and {{GenericDatum::value<>}} that previously
> resolved to the union member type no longer do so (and user code relying on
> that behavior has been broken).
> This change apparently was made as part of the changes for AVRO-1474;
> however, looking at the comments in that issue, it's not clear to me why it
> was required for that fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AVRO-1750) GenericDatum API behavior breaking change
[
https://issues.apache.org/jira/browse/AVRO-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. updated AVRO-1750:
--
Assignee: John McClean
> GenericDatum API behavior breaking change
> -
>
> Key: AVRO-1750
> URL: https://issues.apache.org/jira/browse/AVRO-1750
> Project: Avro
> Issue Type: Bug
> Components: c++
>Affects Versions: 1.7.7
>Reporter: Braden McDaniel
>Assignee: John McClean
> Fix For: 1.8.0
>
>
> It appears that a change was introduced to the {{avro::GenericDatum}}
> implementation between 1.7.6 and 1.7.7 that causes unions to be handled
> differently.
> The 1.7.6 implementation does this:
> {noformat}
> inline Type AVRO_DECL GenericDatum::type() const {
> return (type_ == AVRO_UNION) ?
> boost::any_cast(&value_)->type() : type_;
> }
> template
> const T& GenericDatum::value() const {
> return (type_ == AVRO_UNION) ?
> boost::any_cast(&value_)->value() :
> *boost::any_cast(&value_);
> }
> template
> T& GenericDatum::value() {
> return (type_ == AVRO_UNION) ?
> boost::any_cast(&value_)->value() :
> *boost::any_cast(&value_);
> }
> {noformat}
> …whereas the 1.7.7 implementation does this:
> {noformat}
> /**
> * The avro data type this datum holds.
> */
> Type type() const {
> return type_;
> }
> /**
> * Returns the value held by this datum.
> * T The type for the value. This must correspond to the
> * avro type returned by type().
> */
> template const T& value() const {
> return *boost::any_cast(&value_);
> }
> /**
> * Returns the reference to the value held by this datum, which
> * can be used to change the contents. Please note that only
> * value can be changed, the data type of the value held cannot
> * be changed.
> *
> * T The type for the value. This must correspond to the
> * avro type returned by type().
> */
> template T& value() {
> return *boost::any_cast(&value_);
> }
> {noformat}
> The result of this is that, if the underlying value is an {{AVRO_UNION}},
> calls to {{GenericDatum::type}} and {{GenericDatum::value<>}} that previously
> resolved to the union member type no longer do so (and user code relying on
> that behavior has been broken).
> This change apparently was made as part of the changes for AVRO-1474;
> however, looking at the comments in that issue, it's not clear to me why it
> was required for that fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AVRO-1754) C++ ValiditingDecoder handles null incorrectly
[
https://issues.apache.org/jira/browse/AVRO-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029178#comment-15029178
]
ASF subversion and git services commented on AVRO-1754:
---
Commit 1716757 from [~thiru_mg] in branch 'avro/trunk'
[ https://svn.apache.org/r1716757 ]
AVRO-1754. C++ ValiditingDecoder handles null incorrectly
> C++ ValiditingDecoder handles null incorrectly
> --
>
> Key: AVRO-1754
> URL: https://issues.apache.org/jira/browse/AVRO-1754
> Project: Avro
> Issue Type: Bug
> Components: c++
>Reporter: John McClean
> Attachments: AVRO-1754.patch
>
>
> When decoding null, the ValidatingDecoder does not call the underlying
> 'decodeNull' method. The result is that the next field decoded causes an
> exception.
> For example, if this json
> {quote}
> \{"a":null,"b":"bar"}
> {quote}
> is decoded with this schema
> {quote}
> \{
> "name": "foo",
> "type": "record",
> "fields": [
> \{ "name": "a", "type": ["null", "string"] },
> \{ "name": "b", "type": "string" }
> ]
> }
> {quote}
> it throws an exception with the message "Invalid operation. Expected: String
> got Null". This happens when 'b' is being decoded. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
