[
https://issues.apache.org/jira/browse/AVRO-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Braden McDaniel updated AVRO-1750:
----------------------------------
Description:
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<GenericUnion>(&value_)->type() : type_;
}
template<typename T>
const T& GenericDatum::value() const {
return (type_ == AVRO_UNION) ?
boost::any_cast<GenericUnion>(&value_)->value<T>() :
*boost::any_cast<T>(&value_);
}
template<typename T>
T& GenericDatum::value() {
return (type_ == AVRO_UNION) ?
boost::any_cast<GenericUnion>(&value_)->value<T>() :
*boost::any_cast<T>(&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<typename T> const T& value() const {
return *boost::any_cast<T>(&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<typename T> T& value() {
return *boost::any_cast<T>(&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.
was:
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<GenericUnion>(&value_)->type() : type_;
}
template<typename T>
const T& GenericDatum::value() const {
return (type_ == AVRO_UNION) ?
boost::any_cast<GenericUnion>(&value_)->value<T>() :
*boost::any_cast<T>(&value_);
}
template<typename T>
T& GenericDatum::value() {
return (type_ == AVRO_UNION) ?
boost::any_cast<GenericUnion>(&value_)->value<T>() :
*boost::any_cast<T>(&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<typename T> const T& value() const {
return *boost::any_cast<T>(&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<typename T> T& value() {
return *boost::any_cast<T>(&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 to 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.
> 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
>
> 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<GenericUnion>(&value_)->type() : type_;
> }
> template<typename T>
> const T& GenericDatum::value() const {
> return (type_ == AVRO_UNION) ?
> boost::any_cast<GenericUnion>(&value_)->value<T>() :
> *boost::any_cast<T>(&value_);
> }
> template<typename T>
> T& GenericDatum::value() {
> return (type_ == AVRO_UNION) ?
> boost::any_cast<GenericUnion>(&value_)->value<T>() :
> *boost::any_cast<T>(&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<typename T> const T& value() const {
> return *boost::any_cast<T>(&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<typename T> T& value() {
> return *boost::any_cast<T>(&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)
