[jira] [Updated] (AVRO-1936) avrogencpp, includes should have more guards or generate more headers

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-1936:
--
Status: Patch Available  (was: Open)

> avrogencpp, includes should have more guards or generate more headers
> -
>
> Key: AVRO-1936
> URL: https://issues.apache.org/jira/browse/AVRO-1936
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Affects Versions: 1.8.1
>Reporter: Alexander Moriarty
>Priority: Major
>
> Inside of an avdl file, one can include other avdl files. But the generated 
> only one header file is generated and it does not include guard the 
> enums/structs which were defined in the other avdl files.
> I have some basic records which I've defined in there own avdl files, and 
> include them inside of more complicated structures.
> All is well, until I try to include multiple of the avro generated header 
> files.
> Inside of your AvrogencppTests you have gotten around this by giving each 
> generated type there own name space.
> As a test, I quickly modified the existing avrogencpp.cc to include an 
> optional name to CodeGen::guard.
> {code:none}
> std::string guard(const string& name="");
> [...]
> string CodeGen::guard(const string& name)
> {
> string h = name.empty() ? headerFile_ : name;
> makeCanonical(h, true);
> return h + "_" + lexical_cast(random_()) + "__H_";
> }
> {code}
> And then adding guards around each Enum, Record, Union, Traits, etc.
> Which works well enough. However... the guards do not include the namespace 
> names, so this change breaks your unit tests.
> As long as two higher level classes in the same namespace do not include the 
> same subclasses the generated header files can both be used, but if you have 
> a basic data type like an Point(x,y) which is used throughout the higher 
> level classes then they will both redefine Point(x,y)
> On the Java side, everything is okay. Point(x,y) and all of the classes which 
> include Point are in their own files inside of a package.
> Is there any common way around this problem?



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

[jira] [Updated] (AVRO-1936) avrogencpp, includes should have more guards or generate more headers

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-1936:
--
Component/s: c++

> avrogencpp, includes should have more guards or generate more headers
> -
>
> Key: AVRO-1936
> URL: https://issues.apache.org/jira/browse/AVRO-1936
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Affects Versions: 1.8.1
>Reporter: Alexander Moriarty
>Priority: Major
>
> Inside of an avdl file, one can include other avdl files. But the generated 
> only one header file is generated and it does not include guard the 
> enums/structs which were defined in the other avdl files.
> I have some basic records which I've defined in there own avdl files, and 
> include them inside of more complicated structures.
> All is well, until I try to include multiple of the avro generated header 
> files.
> Inside of your AvrogencppTests you have gotten around this by giving each 
> generated type there own name space.
> As a test, I quickly modified the existing avrogencpp.cc to include an 
> optional name to CodeGen::guard.
> {code:none}
> std::string guard(const string& name="");
> [...]
> string CodeGen::guard(const string& name)
> {
> string h = name.empty() ? headerFile_ : name;
> makeCanonical(h, true);
> return h + "_" + lexical_cast(random_()) + "__H_";
> }
> {code}
> And then adding guards around each Enum, Record, Union, Traits, etc.
> Which works well enough. However... the guards do not include the namespace 
> names, so this change breaks your unit tests.
> As long as two higher level classes in the same namespace do not include the 
> same subclasses the generated header files can both be used, but if you have 
> a basic data type like an Point(x,y) which is used throughout the higher 
> level classes then they will both redefine Point(x,y)
> On the Java side, everything is okay. Point(x,y) and all of the classes which 
> include Point are in their own files inside of a package.
> Is there any common way around this problem?



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

[jira] [Updated] (AVRO-2153) Generating C++ code with avrogencpp produces unclear error message

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-2153:
--
Component/s: c++

> Generating C++ code with avrogencpp produces unclear error message
> --
>
> Key: AVRO-2153
> URL: https://issues.apache.org/jira/browse/AVRO-2153
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Reporter: Nick Byman
>Priority: Minor
>
> If you put a bad name for a json node in an avro file, you can sometimes get: 
> "Exception: boost::too_many_args: format-string referred", when avro is 
> trying to tell you the name of the bad json node, because the node's name 
> isn't passed to boost::format correctly. 



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

[jira] [Updated] (AVRO-2153) Generating C++ code with avrogencpp produces unclear error message

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-2153:
--
Status: Patch Available  (was: Open)

> Generating C++ code with avrogencpp produces unclear error message
> --
>
> Key: AVRO-2153
> URL: https://issues.apache.org/jira/browse/AVRO-2153
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Reporter: Nick Byman
>Priority: Minor
>
> If you put a bad name for a json node in an avro file, you can sometimes get: 
> "Exception: boost::too_many_args: format-string referred", when avro is 
> trying to tell you the name of the bad json node, because the node's name 
> isn't passed to boost::format correctly. 



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

[jira] [Updated] (AVRO-2113) Improve unexpected type error message

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-2113:
--
Fix Version/s: 1.8.3
   Status: Patch Available  (was: Open)

> Improve unexpected type error message
> -
>
> Key: AVRO-2113
> URL: https://issues.apache.org/jira/browse/AVRO-2113
> Project: Avro
>  Issue Type: Improvement
>  Components: c++
>Reporter: Victor Mota
>Assignee: Thiruvalluvan M. G.
>Priority: Minor
> Fix For: 1.8.3
>
>
> Currently the error message for default type mismatch is not very user 
> friendly:
> https://github.com/apache/avro/blob/17f2d75132021fafeca29edbdcade40df960fdc9/lang/c%2B%2B/impl/Compiler.cc#L158
> ie. "Unexpected type for default value: Expected 3, but found 2". Specifying 
> the field where this is happening and what the types mismatched are in human 
> readable format (ie. string, etc) would benefit the user a lot in debugging.
> Here is an example of a user having issues understanding the error: 
> https://issuetracker.google.com/issues/70351564.



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

[jira] [Comment Edited] (AVRO-1340) use default to allow old readers to specify default enum value when encountering new enum symbols

[Bridger Howell (JIRA)]

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

Bridger Howell edited comment on AVRO-1340 at 4/1/18 11:06 PM:
---

# The current PR looks like it has the parser treat anything that is not a 
textual value as if nothing were specified.
 So an enum schema with {{"default": null}} or {{"default": 2}} would be 
successfully parsed, but would have no effect. 
 Otherwise, if the default is a string, it is only successfully parsed if it is 
contained in the enum symbols.
Given that only string values make sense for an enum fallback, I could 
definitely see an argument for raising a parse error in those cases.

 # That seems correct according my understanding of schema resolution and 
reading how {{SchemaCompatibility}} and {{ResolvingGrammarGenerator}} are 
implemented. The idea that only the reader can add support for new writers 
makes sense to me, and it __ should be preserved with the addition of enum 
defaults.

(I'm not completely confident on that answer, however. Any correction or 
confirmation from somebody who has a more comprehensive understanding of schema 
resolution would be helpful.)


was (Author: howellbridger):
# The current PR looks like it has the parser treat anything that is not a 
textual value as if nothing were specified.
So an enum schema with {{"default": null}} or {{"default": 2}} would be 
successfully parsed, but would have no effect. 
Otherwise, if the default is a string, it is only successfully parsed if it is 
contained in the enum symbols.

Given that only string values make sense for an enum fallback, I could 
definitely see an argument for raising a parse error in those cases.
 # That seems correct according my understanding of schema resolution and 
reading how {{SchemaCompatibility}} and {{ResolvingGrammarGenerator}} are 
implemented. The idea that only the reader can add support for new writers 
makes sense to me, and it __ should be preserved with the addition of enum 
defaults.

(I'm not completely confident on that answer, however. Any correction or 
confirmation from somebody who has a more comprehensive understanding of schema 
resolution would be helpful.)

> use default to allow old readers to specify default enum value when 
> encountering new enum symbols
> -
>
> Key: AVRO-1340
> URL: https://issues.apache.org/jira/browse/AVRO-1340
> Project: Avro
>  Issue Type: Improvement
>  Components: spec
> Environment: N/A
>Reporter: Jim Donofrio
>Priority: Minor
>
> The schema resolution page says:
> > if both are enums:
> > if the writer's symbol is not present in the reader's enum, then an
> error is signalled.
> This makes it difficult to use enum's because you can never add a enum value 
> and keep old reader's compatible. Why not use the default option to refer to 
> one of enum values so that when a old reader encounters a enum ordinal it 
> does not recognize, it can default to the optional schema provided one. If 
> the old schema does not provide a default then the older reader can continue 
> to fail as it does today.



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

[jira] [Comment Edited] (AVRO-1340) use default to allow old readers to specify default enum value when encountering new enum symbols

[Bridger Howell (JIRA)]

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

Bridger Howell edited comment on AVRO-1340 at 4/1/18 11:06 PM:
---

# The current PR looks like it has the parser treat anything that is not a 
textual value as if nothing were specified.
 So an enum schema with {{"default": null}} or {{"default": 2}} would be 
successfully parsed, but would have no effect. 
 Otherwise, if the default is a string, it is only successfully parsed if it is 
contained in the enum symbols.
 Given that only string values make sense for an enum fallback, I could 
definitely see an argument for raising a parse error in those cases.
 # That seems correct according my understanding of schema resolution and 
reading how {{SchemaCompatibility}} and {{ResolvingGrammarGenerator}} are 
implemented. The idea that only the reader can add support for new writers 
makes sense to me, and it _should_ be preserved with the addition of enum 
defaults.
(I'm not completely confident on that answer, however. Any correction or 
confirmation from somebody who has a more comprehensive understanding of schema 
resolution would be helpful.)


was (Author: howellbridger):
# The current PR looks like it has the parser treat anything that is not a 
textual value as if nothing were specified.
 So an enum schema with {{"default": null}} or {{"default": 2}} would be 
successfully parsed, but would have no effect. 
 Otherwise, if the default is a string, it is only successfully parsed if it is 
contained in the enum symbols.
Given that only string values make sense for an enum fallback, I could 
definitely see an argument for raising a parse error in those cases.

 # That seems correct according my understanding of schema resolution and 
reading how {{SchemaCompatibility}} and {{ResolvingGrammarGenerator}} are 
implemented. The idea that only the reader can add support for new writers 
makes sense to me, and it __ should be preserved with the addition of enum 
defaults.

(I'm not completely confident on that answer, however. Any correction or 
confirmation from somebody who has a more comprehensive understanding of schema 
resolution would be helpful.)

> use default to allow old readers to specify default enum value when 
> encountering new enum symbols
> -
>
> Key: AVRO-1340
> URL: https://issues.apache.org/jira/browse/AVRO-1340
> Project: Avro
>  Issue Type: Improvement
>  Components: spec
> Environment: N/A
>Reporter: Jim Donofrio
>Priority: Minor
>
> The schema resolution page says:
> > if both are enums:
> > if the writer's symbol is not present in the reader's enum, then an
> error is signalled.
> This makes it difficult to use enum's because you can never add a enum value 
> and keep old reader's compatible. Why not use the default option to refer to 
> one of enum values so that when a old reader encounters a enum ordinal it 
> does not recognize, it can default to the optional schema provided one. If 
> the old schema does not provide a default then the older reader can continue 
> to fail as it does today.



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

[jira] [Commented] (AVRO-1340) use default to allow old readers to specify default enum value when encountering new enum symbols

[Bridger Howell (JIRA)]

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

Bridger Howell commented on AVRO-1340:
--

# The current PR looks like it has the parser treat anything that is not a 
textual value as if nothing were specified.
So an enum schema with {{"default": null}} or {{"default": 2}} would be 
successfully parsed, but would have no effect. 
Otherwise, if the default is a string, it is only successfully parsed if it is 
contained in the enum symbols.

Given that only string values make sense for an enum fallback, I could 
definitely see an argument for raising a parse error in those cases.
 # That seems correct according my understanding of schema resolution and 
reading how {{SchemaCompatibility}} and {{ResolvingGrammarGenerator}} are 
implemented. The idea that only the reader can add support for new writers 
makes sense to me, and it __ should be preserved with the addition of enum 
defaults.

(I'm not completely confident on that answer, however. Any correction or 
confirmation from somebody who has a more comprehensive understanding of schema 
resolution would be helpful.)

> use default to allow old readers to specify default enum value when 
> encountering new enum symbols
> -
>
> Key: AVRO-1340
> URL: https://issues.apache.org/jira/browse/AVRO-1340
> Project: Avro
>  Issue Type: Improvement
>  Components: spec
> Environment: N/A
>Reporter: Jim Donofrio
>Priority: Minor
>
> The schema resolution page says:
> > if both are enums:
> > if the writer's symbol is not present in the reader's enum, then an
> error is signalled.
> This makes it difficult to use enum's because you can never add a enum value 
> and keep old reader's compatible. Why not use the default option to refer to 
> one of enum values so that when a old reader encounters a enum ordinal it 
> does not recognize, it can default to the optional schema provided one. If 
> the old schema does not provide a default then the older reader can continue 
> to fail as it does today.



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

[jira] [Updated] (AVRO-1702) Add LogicalType support to c++ library

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-1702:
--
Status: Patch Available  (was: Open)

There is a pull request for this.

> Add LogicalType support to c++ library
> --
>
> Key: AVRO-1702
> URL: https://issues.apache.org/jira/browse/AVRO-1702
> Project: Avro
>  Issue Type: New Feature
>  Components: c++
>Reporter: peter liu
>Assignee: peter liu
>Priority: Major
>
> I'd like to port the logicaltype support to c++ library



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

[jira] [Resolved] (AVRO-2081) Compilation fails with clang

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. resolved AVRO-2081.
---
   Resolution: Fixed
Fix Version/s: (was: 1.9.0)
   1.8.3

Merged Github pull request

> Compilation fails with clang
> 
>
> Key: AVRO-2081
> URL: https://issues.apache.org/jira/browse/AVRO-2081
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Affects Versions: 1.8.2
> Environment: FreeBSD, clang++ (3.8.0)
>Reporter: Purushotham Nayak
>Assignee: Purushotham Nayak
>Priority: Minor
> Fix For: 1.8.3
>
> Attachments: AVRO-2081.patch
>
>
> Building on {{clang}}  fails with the error below. This is because of the 
> {{vector}} specialization. We need a {{codec_traits}} specialization 
> for {{vector::const_reference}}.
> {code}
> avro/lang/c++/api/Specific.hh:321:22: error: no member named 'encode' in 
> 'avro::codec_traits std::__1::allocator > > >'
> codec_traits::encode(e, t);
> ~^
> avro/lang/c++/api/Specific.hh:235:23: note: in instantiation of function 
> template specialization 
> 'avro::encode std::__1::allocator > > >' requested here
> avro::encode(e, *it);
>   ^
> avro/lang/c++/api/Specific.hh:321:22: note: in instantiation of member 
> function 'avro::codec_traits > >::encode' requested here
> codec_traits::encode(e, t);
>  ^
> {code}



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

[jira] [Commented] (AVRO-2081) Compilation fails with clang

[ASF subversion and git services (JIRA)]

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

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

Commit 8466975290773f5e0d19a16d2c36c05d64ea5134 in avro's branch 
refs/heads/master from [~pnayak]
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=8466975 ]

Fix compilation error caused due to vector specialization.

The codec_traits<> specialization of vector assumes that there is a
codec_traits specialization of type T. It dereferences a
const_iterator pointing to an element in vector to get a
const_reference and then encodes/decodes that element using the
codec_traits specialization.

This works readily with g++ (gcc) where vector::const_reference is
same as bool and we have a codec_traits specialization. However,
in the case of c++ (clang) this vector::const_reference != bool.
So there will be missing specialization for
codec_traits.

Adding the above specialization will fix the clang but will create a
second definition in case of g++ and violate ODR and hence compilation
failure.

This change provides a specialization of
codec_traits if it doesn't already
exist. This should make it work for both c++ and g++. I've also added a
test case to cover this, so we can catch it if future changes in
implementation breaks it or for testing with other implementations.

Fixes AVRO-2081


> Compilation fails with clang
> 
>
> Key: AVRO-2081
> URL: https://issues.apache.org/jira/browse/AVRO-2081
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Affects Versions: 1.8.2
> Environment: FreeBSD, clang++ (3.8.0)
>Reporter: Purushotham Nayak
>Assignee: Purushotham Nayak
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: AVRO-2081.patch
>
>
> Building on {{clang}}  fails with the error below. This is because of the 
> {{vector}} specialization. We need a {{codec_traits}} specialization 
> for {{vector::const_reference}}.
> {code}
> avro/lang/c++/api/Specific.hh:321:22: error: no member named 'encode' in 
> 'avro::codec_traits std::__1::allocator > > >'
> codec_traits::encode(e, t);
> ~^
> avro/lang/c++/api/Specific.hh:235:23: note: in instantiation of function 
> template specialization 
> 'avro::encode std::__1::allocator > > >' requested here
> avro::encode(e, *it);
>   ^
> avro/lang/c++/api/Specific.hh:321:22: note: in instantiation of member 
> function 'avro::codec_traits > >::encode' requested here
> codec_traits::encode(e, t);
>  ^
> {code}



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

[jira] [Commented] (AVRO-2113) Improve unexpected type error message

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. commented on AVRO-2113:
---

Made a pull request: [https://github.com/apache/avro/pull/305.] If there are no 
objections, I'll merge it in a couple of days.

> Improve unexpected type error message
> -
>
> Key: AVRO-2113
> URL: https://issues.apache.org/jira/browse/AVRO-2113
> Project: Avro
>  Issue Type: Improvement
>  Components: c++
>Reporter: Victor Mota
>Assignee: Thiruvalluvan M. G.
>Priority: Minor
>
> Currently the error message for default type mismatch is not very user 
> friendly:
> https://github.com/apache/avro/blob/17f2d75132021fafeca29edbdcade40df960fdc9/lang/c%2B%2B/impl/Compiler.cc#L158
> ie. "Unexpected type for default value: Expected 3, but found 2". Specifying 
> the field where this is happening and what the types mismatched are in human 
> readable format (ie. string, etc) would benefit the user a lot in debugging.
> Here is an example of a user having issues understanding the error: 
> https://issuetracker.google.com/issues/70351564.



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

[jira] [Updated] (AVRO-1191) C++ json encoder uses \U instead of \u

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-1191:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Merged pull request

> C++ json encoder uses \U instead of \u
> --
>
> Key: AVRO-1191
> URL: https://issues.apache.org/jira/browse/AVRO-1191
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Affects Versions: 1.7.0
>Reporter: Keh-Li Sheng
>Priority: Major
> Fix For: 1.8.3
>
>
> From the JSON spec http://www.ietf.org/rfc/rfc4627.txt:
> {quote}
> 2.5.  Strings
>The representation of strings is similar to conventions used in the C
>family of programming languages.  A string begins and ends with
>quotation marks.  All Unicode characters may be placed within the
>quotation marks except for the characters that must be escaped:
>quotation mark, reverse solidus, and the control characters (U+
>through U+001F).
>Any character may be escaped.  If the character is in the Basic
>Multilingual Plane (U+ through U+), then it may be
>represented as a six-character sequence: a reverse solidus, followed
>by the lowercase letter u, followed by four hexadecimal digits that
>encode the character's code point.  The hexadecimal letters A though
>F can be upper or lowercase.  So, for example, a string containing
>only a single reverse solidus character may be represented as
>"\u005C".
> {quote}
> But JsonCodec.cc outputs \U



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

[jira] [Updated] (AVRO-1191) C++ json encoder uses \U instead of \u

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-1191:
--
Fix Version/s: 1.8.3
   Status: Patch Available  (was: Open)

> C++ json encoder uses \U instead of \u
> --
>
> Key: AVRO-1191
> URL: https://issues.apache.org/jira/browse/AVRO-1191
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Affects Versions: 1.7.0
>Reporter: Keh-Li Sheng
>Priority: Major
> Fix For: 1.8.3
>
>
> From the JSON spec http://www.ietf.org/rfc/rfc4627.txt:
> {quote}
> 2.5.  Strings
>The representation of strings is similar to conventions used in the C
>family of programming languages.  A string begins and ends with
>quotation marks.  All Unicode characters may be placed within the
>quotation marks except for the characters that must be escaped:
>quotation mark, reverse solidus, and the control characters (U+
>through U+001F).
>Any character may be escaped.  If the character is in the Basic
>Multilingual Plane (U+ through U+), then it may be
>represented as a six-character sequence: a reverse solidus, followed
>by the lowercase letter u, followed by four hexadecimal digits that
>encode the character's code point.  The hexadecimal letters A though
>F can be upper or lowercase.  So, for example, a string containing
>only a single reverse solidus character may be represented as
>"\u005C".
> {quote}
> But JsonCodec.cc outputs \U



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

[jira] [Commented] (AVRO-1702) Add LogicalType support to c++ library

[Pietro Menna (JIRA)]

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

Pietro Menna commented on AVRO-1702:


[image: Earn.com] 

[image: Pietro] Pietro bounced your email

Pay to resend


Hi there, I'm using Earn.com to automatically bounce emails from outside my
network. It helps me prioritize my inbox and save time! If you're a friend
of mine, click below to request a spot on my whitelist. Your emails will
get through as normal. If I don't know you, go ahead and send me a paid
message. You'll only pay if you get a response. Thanks, Pietro Menna Ruiz
Diaz
How to reach Pietro:

Send a paid message


Request to join free whitelist


This email was sent automatically by Earn.com 
[image: medium]  [image: facebook]
 [image: twitter]


-

*This message was generated in reply to the following message:*

[
https://issues.apache.org/jira/browse/AVRO-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16421705#comment-16421705
] ASF GitHub Bot commented on AVRO-1702:
-- thiru-apache commented on a change
in pull request #302: AVRO-1702: Added support for logical types in the C++
client. URL: https://github.com/apache/avro/pull/302#discussion_r178462148
## File path: lang/c++/impl/LogicalType.cc ## @@ -0,0 +1,89
@@ +/** + * Licensed to the Apache Software Foundation (ASF) under one + *
or more contributor license agreements. See the NOTICE file + * distributed
with this work for additional information + * regarding copyright
ownership. The ASF licenses this file + * to you under the Apache License,
Version 2.0 (the + * "License"); you may not use this file except in
compliance + * with the License. You may obtain a copy of the License at +
* + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by
applicable law or agreed to in writing, software + * distributed under the
License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR
CONDITIONS OF ANY KIND, either express or implied. + * See the License for
the specific language governing permissions and + * limitations under the
License. + */ + +#include "Exception.hh" +#include "LogicalType.hh" +
+namespace avro { + +LogicalType::LogicalType(Type type) + : type_(type),
precision_(0), scale_(0) {} + +LogicalType::Type LogicalType::type() const
{ + return type_; +} + +void LogicalType::setPrecision(int precision) { +
if (type_ != DECIMAL) { + throw Exception("Only logical type DECIMAL can
have precision"); + } + if (precision <= 0) { + throw
Exception(boost::format("Precision cannot be: %1%") % precision); + } +
precision_ = precision; +} + +int LogicalType::precision() const { Review
comment: As a convention in Avro C++, we inline these kind of functions.
That is the body of the function is specified along with the declaration in
`.hpp` file.
 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 LogicalType support to c++ library >
-- > > Key: AVRO-1702 > URL:
https://issues.apache.org/jira/browse/AVRO-1702 > Project: Avro > Issue
Type: New Feature > Components: c++ > Reporter: peter liu > Assignee: peter
liu > Priority: Major > > I'd like to port the logicaltype support to c++
library -- This message was sent by Atlassian JIRA (v7.6.3#76005)


> Add LogicalType support to c++ library
> --
>
> Key: AVRO-1702
> URL: https://issues.apache.org/jira/browse/AVRO-1702
> Project: Avro
>  Issue Type: New Feature
>  Components: c++
>Reporter: peter liu
>Assignee: peter liu
>Priority: Major
>
> I'd like to port the logicaltype support to c++ library



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

[jira] [Commented] (AVRO-1702) Add LogicalType support to c++ library

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AVRO-1702:
--

thiru-apache commented on a change in pull request #302: AVRO-1702: Added 
support for logical types in the C++ client.
URL: https://github.com/apache/avro/pull/302#discussion_r178462148
 
 

 ##
 File path: lang/c++/impl/LogicalType.cc
 ##
 @@ -0,0 +1,89 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "Exception.hh"
+#include "LogicalType.hh"
+
+namespace avro {
+
+LogicalType::LogicalType(Type type)
+: type_(type), precision_(0), scale_(0) {}
+
+LogicalType::Type LogicalType::type() const {
+return type_;
+}
+
+void LogicalType::setPrecision(int precision) {
+if (type_ != DECIMAL) {
+throw Exception("Only logical type DECIMAL can have precision");
+}
+if (precision <= 0) {
+throw Exception(boost::format("Precision cannot be: %1%") % precision);
+}
+precision_ = precision;
+}
+
+int LogicalType::precision() const {
 
 Review comment:
   As a convention in Avro C++, we inline these kind of functions. That is the 
body of the function is specified along with the declaration in `.hpp` file.


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 LogicalType support to c++ library
> --
>
> Key: AVRO-1702
> URL: https://issues.apache.org/jira/browse/AVRO-1702
> Project: Avro
>  Issue Type: New Feature
>  Components: c++
>Reporter: peter liu
>Assignee: peter liu
>Priority: Major
>
> I'd like to port the logicaltype support to c++ library



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

[jira] [Commented] (AVRO-1702) Add LogicalType support to c++ library

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AVRO-1702:
--

thiru-apache commented on a change in pull request #302: AVRO-1702: Added 
support for logical types in the C++ client.
URL: https://github.com/apache/avro/pull/302#discussion_r178461969
 
 

 ##
 File path: lang/c++/impl/Compiler.cc
 ##
 @@ -100,6 +100,17 @@ static NodePtr makeNode(const std::string& t, 
SymbolTable& st, const string& ns)
 throw Exception(boost::format("Unknown type: %1%") % n.fullname());
 }
 
+/** Returns "true" if the field is in the container */
+// e.g.: can be false for non-mandatory fields
+bool containsField(const Entity& e, const Object& m, const string& fieldName) {
+Object::const_iterator it = m.find(fieldName);
+if (it == m.end()) {
 
 Review comment:
   A much simpler expression could be `return (it != m.end())`


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 LogicalType support to c++ library
> --
>
> Key: AVRO-1702
> URL: https://issues.apache.org/jira/browse/AVRO-1702
> Project: Avro
>  Issue Type: New Feature
>  Components: c++
>Reporter: peter liu
>Assignee: peter liu
>Priority: Major
>
> I'd like to port the logicaltype support to c++ library



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

[jira] [Commented] (AVRO-1702) Add LogicalType support to c++ library

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AVRO-1702:
--

thiru-apache commented on a change in pull request #302: AVRO-1702: Added 
support for logical types in the C++ client.
URL: https://github.com/apache/avro/pull/302#discussion_r178461909
 
 

 ##
 File path: lang/c++/api/GenericDatum.hh
 ##
 @@ -54,12 +55,15 @@ namespace avro {
  */
 class AVRO_DECL GenericDatum {
 Type type_;
+LogicalType logicalType_;
 boost::any value_;
 
-GenericDatum(Type t) : type_(t) { }
+GenericDatum(Type t, LogicalType logicalType)
 
 Review comment:
   In order to avoid backward incompatibility, it will be better to continue to 
have the old constructor, (in addition to the new constructor):
   
   GenericDatum(Type t) : type_(t, logicalType(LogicalType::NONE)) { }


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 LogicalType support to c++ library
> --
>
> Key: AVRO-1702
> URL: https://issues.apache.org/jira/browse/AVRO-1702
> Project: Avro
>  Issue Type: New Feature
>  Components: c++
>Reporter: peter liu
>Assignee: peter liu
>Priority: Major
>
> I'd like to port the logicaltype support to c++ library



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

[jira] [Updated] (AVRO-2165) Use nested namespaces in C++ instead of :: separated ones

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-2165:
--
Status: Patch Available  (was: Open)

https://github.com/apache/avro/pull/275

> Use nested namespaces in C++ instead of :: separated ones
> -
>
> Key: AVRO-2165
> URL: https://issues.apache.org/jira/browse/AVRO-2165
> Project: Avro
>  Issue Type: Improvement
>  Components: c++
>Affects Versions: 1.8.2
>Reporter: Thiruvalluvan M. G.
>Priority: Minor
> Fix For: 1.8.3
>
>
> Namespace definitions using colons are supported since C++17 
> ([http://en.cppreference.com/w/cpp/language/namespace]).
> This fix makes the library usable for C++11 and avoids compiler error 
> "Compiler Error C2429" 
> ([https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2429]).



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

[jira] [Updated] (AVRO-2165) Use nested namespaces in C++ instead of :: separated ones

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. updated AVRO-2165:
--
Affects Version/s: 1.8.2
 Priority: Minor  (was: Major)
Fix Version/s: 1.8.3
  Component/s: c++

> Use nested namespaces in C++ instead of :: separated ones
> -
>
> Key: AVRO-2165
> URL: https://issues.apache.org/jira/browse/AVRO-2165
> Project: Avro
>  Issue Type: Improvement
>  Components: c++
>Affects Versions: 1.8.2
>Reporter: Thiruvalluvan M. G.
>Priority: Minor
> Fix For: 1.8.3
>
>
> Namespace definitions using colons are supported since C++17 
> ([http://en.cppreference.com/w/cpp/language/namespace]).
> This fix makes the library usable for C++11 and avoids compiler error 
> "Compiler Error C2429" 
> ([https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2429]).



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

[jira] [Created] (AVRO-2165) Use nested namespaces in C++ instead of :: separated ones

[Thiruvalluvan M. G. (JIRA)]

Thiruvalluvan M. G. created AVRO-2165:
-

 Summary: Use nested namespaces in C++ instead of :: separated ones
 Key: AVRO-2165
 URL: https://issues.apache.org/jira/browse/AVRO-2165
 Project: Avro
  Issue Type: Improvement
Reporter: Thiruvalluvan M. G.


Namespace definitions using colons are supported since C++17 
([http://en.cppreference.com/w/cpp/language/namespace]).
This fix makes the library usable for C++11 and avoids compiler error "Compiler 
Error C2429" 
([https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2429]).



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

[jira] [Assigned] (AVRO-2113) Improve unexpected type error message

[Thiruvalluvan M. G. (JIRA)]

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

Thiruvalluvan M. G. reassigned AVRO-2113:
-

Assignee: Thiruvalluvan M. G.

> Improve unexpected type error message
> -
>
> Key: AVRO-2113
> URL: https://issues.apache.org/jira/browse/AVRO-2113
> Project: Avro
>  Issue Type: Improvement
>  Components: c++
>Reporter: Victor Mota
>Assignee: Thiruvalluvan M. G.
>Priority: Minor
>
> Currently the error message for default type mismatch is not very user 
> friendly:
> https://github.com/apache/avro/blob/17f2d75132021fafeca29edbdcade40df960fdc9/lang/c%2B%2B/impl/Compiler.cc#L158
> ie. "Unexpected type for default value: Expected 3, but found 2". Specifying 
> the field where this is happening and what the types mismatched are in human 
> readable format (ie. string, etc) would benefit the user a lot in debugging.
> Here is an example of a user having issues understanding the error: 
> https://issuetracker.google.com/issues/70351564.



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