[jira] [Commented] (AVRO-1788) python api differs unnecessarily between python2 and python3

[Samuel Taylor (JIRA)]

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

Samuel Taylor commented on AVRO-1788:
-

This is an issue. I'm happy to work on this if someone can point me in the 
right direction!

> python api differs unnecessarily between python2 and python3
> 
>
> Key: AVRO-1788
> URL: https://issues.apache.org/jira/browse/AVRO-1788
> Project: Avro
>  Issue Type: Wish
>Reporter: Alexander Hasha
>Priority: Minor
>
> It is difficult to use the python avro module in projects that maintain 
> simultaneous compatibility between python 2 and python 3, because there are 
> small differences in the API between the two versions in the module that seem 
> unnecessary.
> For example, to parse a schema string in python 2:
> {code}
> from avro.schema import parse
> {code}
> and in python 3:
> {code}
> from avro.schema import Parse
> {code}
> In Python2, DatumReader's constructor has keyword argument "writers_schema", 
> and in Python 3 it becomes "writer_schema" (no s).
> Would it be possible to align method names and arguments across the two 
> modules?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] avro pull request #131: Avro1363 C# union schema can now contain multiple en...

[Simon24601]

GitHub user Simon24601 opened a pull request:

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

Avro1363  C# union schema can now contain multiple entries with the same 
name and different namespace

When processing a UnionSchema, we store a list of all the names that have 
already been processed. In Java, the fully-resolved names are used (including 
namespaces), while in C# only the simple name was used. This means that a 
UnionSchema cannot contain multiple entries with the same name and different 
namespaces. 

I've fixed this by making the code more like the Java, i.e. adding a 
Fullname method to the base Schema class, and using this when processing the 
UnionSchema. 

I have not checked for the same issue in other languages. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Simon24601/avro AVRO1363

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/avro/pull/131.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #131


commit a2718fed6f8e32073ae71292b49d843adb65643d
Author: Simon Woodford 
Date:   2016-05-23T23:22:33Z

AVRO-1849 Fix the issue where converting the schema of a record with no 
fields produced an invalid JSON

commit 58ecc80a08d0df711ca89dc94ebe97de61b26e5d
Author: Simon24601 
Date:   2016-09-14T10:17:09Z

Merge remote-tracking branch 'avroMain/master'

commit 700af696cea8f66aad371e1472c42972e78aefe3
Author: srw 
Date:   2016-09-14T22:26:01Z

Merge branch 'master' of https://github.com/apache/avro

commit 39c5195c4ac0d404296e88aa7beda91308405cd1
Author: srw 
Date:   2016-09-22T22:38:43Z

Fix style issues in the code.

commit 3f0ec2cf6f36f64e3775880773f6488827d2492b
Author: srw 
Date:   2016-09-22T22:55:20Z

Merge branch 'master' of https://github.com/apache/avro

commit d3d0aa84daba998f084140a0c82633babe561a50
Author: srw 
Date:   2016-09-22T22:59:29Z

Merge branch 'master' of https://github.com/Simon24601/avro

commit e80fd1aa4c9cc8b5cccbb35a33903d6988109172
Author: srw 
Date:   2016-09-24T00:47:55Z

Fix the build scripts; build.sh requires the :z addition to work on SELinux 
(see Jira 1925). lang/c++/build.sh refers to the lang/c++/build directory which 
is empty. These are now fixed.

commit f7826c623a73c8daccdaae618f8eeb58cd601dd7
Author: srw 
Date:   2016-09-24T00:54:57Z

Update to use BOOST_TEST_CHECKPOINT

commit 3ad5aaca13a0b82b42090139b7f1369e0e65427d
Author: srw 
Date:   2016-09-26T22:16:44Z

AVRO-1926 Revert changes to the lang/c++/build.sh script and add the 
SchemaTests to the list of tests. Also revert SELinux changes to build.sh as 
these should be committed separately

commit 800247f9a7003a2313d5ae9dad8feaf261f7ddfc
Author: srw 
Date:   2016-09-26T23:11:50Z

AVRO-1363 Fix the parsing of a union schema with duplicate names but 
different namespaces. In Java, this works, but not in C#

commit e424f9fcec9632573e684bb11b231ef48695d005
Author: srw 
Date:   2016-09-26T23:23:46Z

Remove c++ changes from the AVRO1363 branch




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (AVRO-1919) formalize the presence of build.sh.

[Doug Cutting (JIRA)]

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

Doug Cutting updated AVRO-1919:
---
   Resolution: Fixed
Fix Version/s: 1.8.2
   1.9.0
   Status: Resolved  (was: Patch Available)

I committed this.  Thanks, Suraj!

> formalize the presence of build.sh.
> ---
>
> Key: AVRO-1919
> URL: https://issues.apache.org/jira/browse/AVRO-1919
> Project: Avro
>  Issue Type: Task
>  Components: build
>Reporter: Suraj Acharya
>Assignee: Suraj Acharya
>Priority: Minor
> Fix For: 1.9.0, 1.8.2
>
> Attachments: AVRO-1919.patch
>
>
> After discussing with yetus community we will need a build.sh for every 
> language.
> Currently it is present for a few and not for all 
> {code}
> Busbey-MBA:avro busbey$ find . -name build.sh
> ./build.sh
> ./lang/c/build.sh
> ./lang/c++/build.sh
> ./lang/csharp/build.sh
> ./lang/js/build.sh
> ./lang/php/build.sh
> ./lang/ruby/build.sh
> {code}
> The objective of this task is to create a build.sh for each of the languages.
> It might be good idea to refactor the top level build.sh to use the new 
> build.sh scripts like it does for other languages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1919) formalize the presence of build.sh.

[ASF subversion and git services (JIRA)]

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

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

Commit ab25bf2037f98a2fc99179b8ee175d3d876f87b3 in avro's branch 
refs/heads/master from [~cutting]
[ https://git-wip-us.apache.org/repos/asf?p=avro.git;h=ab25bf2 ]

AVRO-1919: Formalize the presence of build.sh.  Contributed by Suraj Acharya.


> formalize the presence of build.sh.
> ---
>
> Key: AVRO-1919
> URL: https://issues.apache.org/jira/browse/AVRO-1919
> Project: Avro
>  Issue Type: Task
>  Components: build
>Reporter: Suraj Acharya
>Assignee: Suraj Acharya
>Priority: Minor
> Attachments: AVRO-1919.patch
>
>
> After discussing with yetus community we will need a build.sh for every 
> language.
> Currently it is present for a few and not for all 
> {code}
> Busbey-MBA:avro busbey$ find . -name build.sh
> ./build.sh
> ./lang/c/build.sh
> ./lang/c++/build.sh
> ./lang/csharp/build.sh
> ./lang/js/build.sh
> ./lang/php/build.sh
> ./lang/ruby/build.sh
> {code}
> The objective of this task is to create a build.sh for each of the languages.
> It might be good idea to refactor the top level build.sh to use the new 
> build.sh scripts like it does for other languages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AVRO-1926) lang/c++ build.sh doesn't work

[Simon Woodford (JIRA)]

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

Simon Woodford resolved AVRO-1926.
--
Resolution: Cannot Reproduce

Deleting everything and checking out a fresh version seems to have fixed the 
issue. 

> lang/c++ build.sh  doesn't work
> ---
>
> Key: AVRO-1926
> URL: https://issues.apache.org/jira/browse/AVRO-1926
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Affects Versions: 1.8.1
> Environment: Centos 7, SELinux, running from Docker container
>Reporter: Simon Woodford
>Priority: Minor
> Fix For: 1.8.3
>
>
> The lang/c++/build.sh script makes frequent reference to the build directory, 
> which is empty. Instead, make and all tests should be launched directly from 
> lang/c++. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AVRO-1928) Python double/float encoding implementation should use built-in struct support for little endian

[Shalabh Chaturvedi (JIRA)]

Shalabh Chaturvedi created AVRO-1928:


 Summary: Python double/float encoding implementation should use 
built-in struct support for little endian
 Key: AVRO-1928
 URL: https://issues.apache.org/jira/browse/AVRO-1928
 Project: Avro
  Issue Type: Improvement
  Components: python
Affects Versions: 1.8.1
Reporter: Shalabh Chaturvedi
Priority: Minor


The encoding and decoding of double and float types in Python uses unnecessary 
bit operations and packing/unpacking. Python's {{struct}} module supports 
little-endian encoding and could be used directly, instead of using the 
big-endian and then bit-fiddling to reverse the endianness.

This could have a big impact of encoding/decoding speed of large buffers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1923) Recursive record causes StackOverflow in GenericData.toString

[Doug Cutting (JIRA)]

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

Doug Cutting commented on AVRO-1923:


Elsewhere in Avro we handle circular structures by keeping track of previously 
seen objects, with no limit on the depth of circularity.  So this might instead 
look something like:
{code}
public String toString(Object o, StringBuffer b) {
  return toStringInternal(o, b, new IdentityHashMap());
}
public String toString(Object o, StringBuffer b, Map seen) {
  if (seen.containsKey(o))
return ... ; // circle detected 
  try {
seen.put(o, o);
... prior toString logic ...
  } finally {
seen.remove(o);
  }
}
{code}

> Recursive record causes StackOverflow in GenericData.toString
> -
>
> Key: AVRO-1923
> URL: https://issues.apache.org/jira/browse/AVRO-1923
> Project: Avro
>  Issue Type: Bug
>Reporter: Niels Basjes
>Assignee: Niels Basjes
> Attachments: AVRO-1923-Unittest.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1918) Improve logical type documentation

[Doug Cutting (JIRA)]

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

Doug Cutting commented on AVRO-1918:


This looks great.  Some comments.

- SpecificCompiler.java now pre-defines four logical type conversions, date, 
time, timestamp and decimal.  These should be listed in package.html.

- It would be better to provide examples of all of the logical types supported 
in the IDL documentation, so also include "date" and "time_ms".

Thanks!

> Improve logical type documentation
> --
>
> Key: AVRO-1918
> URL: https://issues.apache.org/jira/browse/AVRO-1918
> Project: Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: Doug Cutting
>Assignee: Gabor Szadovszky
>
> AVRO-1684 added support for logical types.
> It would be good to add to the IDL documentation some examples of how logical 
> types can be used from IDL.
> We should also update the org.apache.avro.specific documentation indicating 
> the now pre-defined logical type mappings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AVRO-1860) DefaultValue() returns Ints for Long fields

[Zoltan Ivanfi (JIRA)]

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

Zoltan Ivanfi updated AVRO-1860:

Component/s: java

> DefaultValue() returns Ints for Long fields
> ---
>
> Key: AVRO-1860
> URL: https://issues.apache.org/jira/browse/AVRO-1860
> Project: Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.8.1
>Reporter: Manuel Rieke
>
> I am iterating over the schemas for getting default values for fields. When 
> the type of a field is Long Avro returns INT instead:
> field.defaultVal()
> -->Field.defaultVal()
> -->Jacksonutils.toObject(jsonNode)
> -->Jacksonutils.toObject(jsonNode, null)
> The Field class already contains the information ("long"), so shouldn't the 
> Field class use Jacksonutils-toObject-Method with schema? Otherwise it is 
> always null and Integer are returned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1909) Make concat tool handle directories as input

[Sebastian Wallin (JIRA)]

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

Sebastian Wallin commented on AVRO-1909:


The pull request on Github has been approved by [~gszadovszky]. What's the next 
step for merging this?

> Make concat tool handle directories as input
> 
>
> Key: AVRO-1909
> URL: https://issues.apache.org/jira/browse/AVRO-1909
> Project: Avro
>  Issue Type: Improvement
>  Components: java
>Affects Versions: 1.8.1
>Reporter: Sebastian Wallin
>Priority: Minor
>
> I'm having a situation where I want to concatenate thousands of files in a 
> directory. Currently this generates `Argument list too long` when the shell 
> tries to expand into a list of files.
> It would be great for the `concat` tool to handle directories as input for 
> use cases like this, as well as being consistent with the `cat` tool
> There is a similar issue filed (AVRO-1787), which requests both directories 
> and glob patters to be handled. IMHO it would be enough to make the `concat` 
> tool handle directories, as a start. It would also require a lot less code to 
> be changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1926) lang/c++ build.sh doesn't work

[Zoltan Ivanfi (JIRA)]

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

Zoltan Ivanfi commented on AVRO-1926:
-

Hi Simon,

Things seem to work differently in our environments. On my computer, CMake 
generates a `Makefile` in the `build` directory, thus the `make` commands work 
correctly when issued from there. When launched directly from `lang/c++` 
though, `make` fails because there is no `Makefile` there. I don't know why you 
experience a different behaviour. Did you apply any customizations to your dev 
environment?

Zoltan

> lang/c++ build.sh  doesn't work
> ---
>
> Key: AVRO-1926
> URL: https://issues.apache.org/jira/browse/AVRO-1926
> Project: Avro
>  Issue Type: Bug
>  Components: c++
>Affects Versions: 1.8.1
> Environment: Centos 7, SELinux, running from Docker container
>Reporter: Simon Woodford
>Priority: Minor
> Fix For: 1.8.3
>
>
> The lang/c++/build.sh script makes frequent reference to the build directory, 
> which is empty. Instead, make and all tests should be launched directly from 
> lang/c++. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1605) Remove Jackson classes from public API

[Gabor Szadovszky (JIRA)]

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

Gabor Szadovszky commented on AVRO-1605:


Thanks for the link, [~tomwhite]. Now, it's clear. :)

How strict shall I be when removing the Jackson classes from the API? Is it 
fine to keep something deprecated with the note of "internal use only" or shall 
I try to refactor all the invocations to use it really internally 
(private/package private) or use the related public API?

> Remove Jackson classes from public API
> --
>
> Key: AVRO-1605
> URL: https://issues.apache.org/jira/browse/AVRO-1605
> Project: Avro
>  Issue Type: Sub-task
>  Components: java
>Affects Versions: 1.7.8
>Reporter: Tom White
>Assignee: Gabor Szadovszky
> Fix For: 1.9.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (AVRO-1605) Remove Jackson classes from public API

[Gabor Szadovszky (JIRA)]

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

Work on AVRO-1605 started by Gabor Szadovszky.
--
> Remove Jackson classes from public API
> --
>
> Key: AVRO-1605
> URL: https://issues.apache.org/jira/browse/AVRO-1605
> Project: Avro
>  Issue Type: Sub-task
>  Components: java
>Affects Versions: 1.7.8
>Reporter: Tom White
>Assignee: Gabor Szadovszky
> Fix For: 1.9.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (AVRO-1605) Remove Jackson classes from public API

[Gabor Szadovszky (JIRA)]

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

Gabor Szadovszky reassigned AVRO-1605:
--

Assignee: Gabor Szadovszky

> Remove Jackson classes from public API
> --
>
> Key: AVRO-1605
> URL: https://issues.apache.org/jira/browse/AVRO-1605
> Project: Avro
>  Issue Type: Sub-task
>  Components: java
>Affects Versions: 1.7.8
>Reporter: Tom White
>Assignee: Gabor Szadovszky
> Fix For: 1.9.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AVRO-1907) Add logging to logical type handling in java library

[Gabor Szadovszky (JIRA)]

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

Gabor Szadovszky updated AVRO-1907:
---
Status: Patch Available  (was: Open)

> Add logging to logical type handling in java library
> 
>
> Key: AVRO-1907
> URL: https://issues.apache.org/jira/browse/AVRO-1907
> Project: Avro
>  Issue Type: Improvement
>  Components: java
>Affects Versions: 1.8.0
>Reporter: Sean Busbey
>Assignee: Gabor Szadovszky
>
> Right now we don't have any logging while handling logical type information 
> in a Schema. In particular, we use {{LogicalTypes.fromSchemaIgnoreInvalid}} 
> which means when folks have a problem in their schema logical types just 
> disappear with no debugging information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (AVRO-1907) Add logging to logical type handling in java library

[Gabor Szadovszky (JIRA)]

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

Gabor Szadovszky reassigned AVRO-1907:
--

Assignee: Gabor Szadovszky

> Add logging to logical type handling in java library
> 
>
> Key: AVRO-1907
> URL: https://issues.apache.org/jira/browse/AVRO-1907
> Project: Avro
>  Issue Type: Improvement
>  Components: java
>Affects Versions: 1.8.0
>Reporter: Sean Busbey
>Assignee: Gabor Szadovszky
>
> Right now we don't have any logging while handling logical type information 
> in a Schema. In particular, we use {{LogicalTypes.fromSchemaIgnoreInvalid}} 
> which means when folks have a problem in their schema logical types just 
> disappear with no debugging information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1907) Add logging to logical type handling in java library

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AVRO-1907:
--

GitHub user gszadovszky opened a pull request:

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

AVRO-1907 - Add logging to logical type handling in java library

Didn't find other parts related to logical type handling where we would 
swallow an exception and therefore, some logging is required. 
Please, review and comment any idea if I should look into something more 
deeply.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gszadovszky/avro AVRO-1907

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/avro/pull/130.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #130


commit 8810a93e00880396c7251e38defe97e3d41ba6f8
Author: Gabor Szadovszky 
Date:   2016-09-26T11:44:25Z

AVRO-1907 - Add logging to logical type handling in java library




> Add logging to logical type handling in java library
> 
>
> Key: AVRO-1907
> URL: https://issues.apache.org/jira/browse/AVRO-1907
> Project: Avro
>  Issue Type: Improvement
>  Components: java
>Affects Versions: 1.8.0
>Reporter: Sean Busbey
>
> Right now we don't have any logging while handling logical type information 
> in a Schema. In particular, we use {{LogicalTypes.fromSchemaIgnoreInvalid}} 
> which means when folks have a problem in their schema logical types just 
> disappear with no debugging information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] avro pull request #130: AVRO-1907 - Add logging to logical type handling in ...

[gszadovszky]

GitHub user gszadovszky opened a pull request:

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

AVRO-1907 - Add logging to logical type handling in java library

Didn't find other parts related to logical type handling where we would 
swallow an exception and therefore, some logging is required. 
Please, review and comment any idea if I should look into something more 
deeply.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gszadovszky/avro AVRO-1907

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/avro/pull/130.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #130


commit 8810a93e00880396c7251e38defe97e3d41ba6f8
Author: Gabor Szadovszky 
Date:   2016-09-26T11:44:25Z

AVRO-1907 - Add logging to logical type handling in java library




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (AVRO-1605) Remove Jackson classes from public API

[Tom White (JIRA)]

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

Tom White commented on AVRO-1605:
-

Although very rare, backward incompatible changes to the API are permitted in 
minor releases:

https://mail-archives.apache.org/mod_mbox/avro-user/201302.mbox/%3ccaleq1z9kzaswldnn4c-xjv1p6bpykf3e5ga+fxzjqprja3p...@mail.gmail.com%3E

Note that changes to the data format are only allowed in major releases.

> Remove Jackson classes from public API
> --
>
> Key: AVRO-1605
> URL: https://issues.apache.org/jira/browse/AVRO-1605
> Project: Avro
>  Issue Type: Sub-task
>  Components: java
>Affects Versions: 1.7.8
>Reporter: Tom White
> Fix For: 1.9.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1885) Release 1.8.2

[Niels Basjes (JIRA)]

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

Niels Basjes commented on AVRO-1885:


I would really like to have this one fixed.

> Release 1.8.2
> -
>
> Key: AVRO-1885
> URL: https://issues.apache.org/jira/browse/AVRO-1885
> Project: Avro
>  Issue Type: Task
>  Components: community
>Affects Versions: 1.8.2
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 1.8.2
>
>
> Please link to any issues that should be considered blockers for the 1.8.2 
> release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1924) Variable named 'date' in IDL

[Niels Basjes (JIRA)]

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

Niels Basjes commented on AVRO-1924:


Although uncommon I essentially think this should be valid:
{code:java|title=share/test/schemas/specialtypes.avdl }
record keywordsAsVariableNames {
  string  array;
  string  boolean;
  string  double;
  string  enum;
  string  error;
  string  false;
  string  fixed;
  string  float;
  string  idl;
  string  import;
  string  int;
  string  long;
  string  map;
  string  oneway;
  string  bytes;
  string  schema;
  string  string;
  string  null;
  string  protocol;
  string  record;
  string  throws;
  string  true;
  string  union;
  string  void;
  string  date;
  string  time_ms;
  string  timestamp_ms;
  string  decimal;
}
{code}

Is this desirable?
Is this doable in the JavaCC ?
Is this doable in the other languages?

> Variable named 'date' in IDL
> 
>
> Key: AVRO-1924
> URL: https://issues.apache.org/jira/browse/AVRO-1924
> Project: Avro
>  Issue Type: Bug
>Reporter: Niels Basjes
>Assignee: Ryan Blue
>
> I was compiling Apache Parquet and found that the switch from Avro 1.8.0 to 
> 1.8.1 broke their build.
> The error: {code}
> [ERROR] Failed to execute goal 
> org.apache.avro:avro-maven-plugin:1.8.1:idl-protocol (schemas) ... 
> org.apache.avro.compiler.idl.ParseException: Encountered " "date" "date "" at 
> line 23, column 14.
> [ERROR] Was expecting one of:
> [ERROR]  ...
> [ERROR] "@" ...
> [ERROR] "`" ...
> [ERROR] -> [Help 1]
> {code}
> As it turns out they have a test idl that contains this:
> {code}
> @namespace("org.apache.parquet.avro")
> protocol Cars {
> record Service {
> long date;
> }
> }
> {code}
> And this change AVRO-1684 turned the word 'date' into something different for 
> the idl compiler.
> So changing the word 'date' into something else fixes the problem. 
> Yet I think this is an undesirable effect for end user applications.
> [~rdblue]: I assigned this to you implemented the mentioned change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1865) GenericData.Array class missing no arg constructor for Kryo serialization

[Gabor Szadovszky (JIRA)]

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

Gabor Szadovszky commented on AVRO-1865:


What do you think about make the new parameterless constructor deprecated? I 
know, deprecation does not suppose to only mean that you should not use 
something but at least it helps to highlight that fact in an IDE or with java 
warnings.


> GenericData.Array class missing no arg constructor for Kryo serialization
> -
>
> Key: AVRO-1865
> URL: https://issues.apache.org/jira/browse/AVRO-1865
> Project: Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.8.1
>Reporter: Alexander Kasper
>  Labels: newbie, patch
> Attachments: GenericArray-no-args-ctor-kryo.patch
>
>
> When trying to serialize Java classes generated by Avro that contain a field 
> as follows:
> {{array myclasses = []}}
> serialization fails with the following error message
> {{com.esotericsoftware.kryo.KryoException: Class cannot be created (missing 
> no-arg constructor)}}
> Minimum example to recreate this:
> Avro IDL definition:
> {code:java}
> @namespace("com.adello")
> protocol KryoTest {
>   record TestRecord {
>   array values = [];
>   }
> }
> {code}
> This gets compiled using {{java -jar avro-tools-1.8.1.jar idl2schemata 
> kryo.avdl .}}
> Resulting Avro schema:
> {code:javascript}
> {
>   "type" : "record",
>   "name" : "TestRecord",
>   "namespace" : "com.adello",
>   "fields" : [ {
> "name" : "values",
> "type" : {
>   "type" : "array",
>   "items" : "int"
> },
> "default" : [ ]
>   } ]
> }
> {code}
> Generate Java class using {{java -jar avro-tools-1.8.1.jar compile schema 
> TestRecord.avsc}}
> Kryo serialization test code:
> {code:java}
> Kryo kryo = new Kryo();
> try {
> Output output = new Output(new FileOutputStream("test.bin"));
> TestRecord o = TestRecord.newBuilder().build();
> System.out.println("Before serialization: ");
> System.out.println(o.toString());
> kryo.writeObject(output, o);
> output.close();
> Input input = new Input(new FileInputStream("test.bin"));
> TestRecord i = kryo.readObject(input, TestRecord.class);
> input.close();
> System.out.println("After deserialization: ");
> System.out.println(i.toString());
> System.out.println(Objects.deepEquals(o, i));
> } catch (FileNotFoundException e) {
> e.printStackTrace();
> }
> {code}
> This is a common enough issue with Kryo that they have a dedicated section on 
> their website on it: 
> http://docs.datatorrent.com/troubleshooting/#application-throwing-following-kryo-exception
> The attached patch adds a no args constructor for the inner class Array of 
> GenericData with zero entries and a dummy schema. My personal tests for 
> serialization with Kryo were successful when using it. Since I do not have 
> complete insight into Avro I'd like to know if this could be a breaking 
> change and how to test it if so.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1605) Remove Jackson classes from public API

[Gabor Szadovszky (JIRA)]

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

Gabor Szadovszky commented on AVRO-1605:


I do not know (and failed to find info about) the versioning strategy of Avro. 
Is it usual that we do backward incompatible changes in minor releases (in 
terms of semantic versioning)?

> Remove Jackson classes from public API
> --
>
> Key: AVRO-1605
> URL: https://issues.apache.org/jira/browse/AVRO-1605
> Project: Avro
>  Issue Type: Sub-task
>  Components: java
>Affects Versions: 1.7.8
>Reporter: Tom White
> Fix For: 1.9.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AVRO-1918) Improve logical type documentation

[Gabor Szadovszky (JIRA)]

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

Gabor Szadovszky updated AVRO-1918:
---
Status: Patch Available  (was: In Progress)

> Improve logical type documentation
> --
>
> Key: AVRO-1918
> URL: https://issues.apache.org/jira/browse/AVRO-1918
> Project: Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: Doug Cutting
>Assignee: Gabor Szadovszky
>
> AVRO-1684 added support for logical types.
> It would be good to add to the IDL documentation some examples of how logical 
> types can be used from IDL.
> We should also update the org.apache.avro.specific documentation indicating 
> the now pre-defined logical type mappings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (AVRO-1918) Improve logical type documentation

[Gabor Szadovszky (JIRA)]

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

Gabor Szadovszky reassigned AVRO-1918:
--

Assignee: Gabor Szadovszky

> Improve logical type documentation
> --
>
> Key: AVRO-1918
> URL: https://issues.apache.org/jira/browse/AVRO-1918
> Project: Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: Doug Cutting
>Assignee: Gabor Szadovszky
>
> AVRO-1684 added support for logical types.
> It would be good to add to the IDL documentation some examples of how logical 
> types can be used from IDL.
> We should also update the org.apache.avro.specific documentation indicating 
> the now pre-defined logical type mappings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1918) Improve logical type documentation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AVRO-1918:
--

GitHub user gszadovszky opened a pull request:

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

AVRO-1918 - Improve logical type documentation

Tried to understand the related change (AVRO-1684) and do the docs update. 
Please, review and comment if it is correct and enough.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gszadovszky/avro AVRO-1918

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/avro/pull/129.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #129


commit 84a71cfa721bfefd2edf08d5d278e4b8095d18f4
Author: Gabor Szadovszky 
Date:   2016-09-26T07:59:24Z

AVRO-1918 - Improve logical type documentation




> Improve logical type documentation
> --
>
> Key: AVRO-1918
> URL: https://issues.apache.org/jira/browse/AVRO-1918
> Project: Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: Doug Cutting
>
> AVRO-1684 added support for logical types.
> It would be good to add to the IDL documentation some examples of how logical 
> types can be used from IDL.
> We should also update the org.apache.avro.specific documentation indicating 
> the now pre-defined logical type mappings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] avro pull request #129: AVRO-1918 - Improve logical type documentation

[gszadovszky]

GitHub user gszadovszky opened a pull request:

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

AVRO-1918 - Improve logical type documentation

Tried to understand the related change (AVRO-1684) and do the docs update. 
Please, review and comment if it is correct and enough.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gszadovszky/avro AVRO-1918

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/avro/pull/129.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #129


commit 84a71cfa721bfefd2edf08d5d278e4b8095d18f4
Author: Gabor Szadovszky 
Date:   2016-09-26T07:59:24Z

AVRO-1918 - Improve logical type documentation




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---