[jira] [Commented] (AVRO-2366) setValidateDefaults=false does not seem to work

[Rumeshkrishnan (JIRA)]

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

Rumeshkrishnan commented on AVRO-2366:
--

Hi [~rocketraman], Can you give me sample test case ? I will help you to fix 
this.

> setValidateDefaults=false does not seem to work
> ---
>
> Key: AVRO-2366
> URL: https://issues.apache.org/jira/browse/AVRO-2366
> Project: Apache Avro
>  Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Raman Gupta
>Priority: Major
>
> Followup to AVRO-2035.
> I am testing 1.9 SNAPSHOT. I set `Schema.Parser.setValidateDefaults` to 
> false, and still get a failure at compile-time if the default does not match 
> the schema. For example, a field definition of:
> {"name": "name", "type": "string", "default": null}
> Should this definition succeed if `setValidateDefaults(false)` is called? If 
> not, should the `setValidateDefaults` method just be removed?
> The exception is:
> Caused by: org.apache.avro.AvroTypeException: Invalid default for field name: 
> null not a {"type":"string","avro.java.string":"String"}
>   at org.apache.avro.Schema.validateDefault(Schema.java:1482)
>   at org.apache.avro.Schema.access$300(Schema.java:84)
>   at org.apache.avro.Schema$Field.(Schema.java:493)
>   at org.apache.avro.Schema$Field.(Schema.java:485)
>   at org.apache.avro.Schema$Field.(Schema.java:504)
>   at 
> org.apache.avro.compiler.specific.SpecificCompiler.addStringType(SpecificCompiler.java:689)
>   at 
> org.apache.avro.compiler.specific.SpecificCompiler.addStringType(SpecificCompiler.java:668)
>   at 
> org.apache.avro.compiler.specific.SpecificCompiler.compile(SpecificCompiler.java:598)
>   at 
> org.apache.avro.compiler.specific.SpecificCompiler.compileToDestination(SpecificCompiler.java:527)



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

[jira] [Updated] (AVRO-2366) setValidateDefaults=false does not seem to work

[Raman Gupta (JIRA)]

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

Raman Gupta updated AVRO-2366:
--
Summary: setValidateDefaults=false does not seem to work  (was: 1.9 )

> setValidateDefaults=false does not seem to work
> ---
>
> Key: AVRO-2366
> URL: https://issues.apache.org/jira/browse/AVRO-2366
> Project: Apache Avro
>  Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Raman Gupta
>Priority: Major
>
> Followup to AVRO-2035.
> I am testing 1.9 SNAPSHOT. I set `Schema.Parser.setValidateDefaults` to 
> false, and still get a failure at compile-time if the default does not match 
> the schema. For example, a field definition of:
> {"name": "name", "type": "string", "default": null}
> Should this definition succeed if `setValidateDefaults(false)` is called? If 
> not, should the `setValidateDefaults` method just be removed?
> The exception is:
> Caused by: org.apache.avro.AvroTypeException: Invalid default for field name: 
> null not a {"type":"string","avro.java.string":"String"}
>   at org.apache.avro.Schema.validateDefault(Schema.java:1482)
>   at org.apache.avro.Schema.access$300(Schema.java:84)
>   at org.apache.avro.Schema$Field.(Schema.java:493)
>   at org.apache.avro.Schema$Field.(Schema.java:485)
>   at org.apache.avro.Schema$Field.(Schema.java:504)
>   at 
> org.apache.avro.compiler.specific.SpecificCompiler.addStringType(SpecificCompiler.java:689)
>   at 
> org.apache.avro.compiler.specific.SpecificCompiler.addStringType(SpecificCompiler.java:668)
>   at 
> org.apache.avro.compiler.specific.SpecificCompiler.compile(SpecificCompiler.java:598)
>   at 
> org.apache.avro.compiler.specific.SpecificCompiler.compileToDestination(SpecificCompiler.java:527)



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

Re: [VOTE] Release Apache Avro 1.9.0 RC1

[Daniel Kulp]

Two minor issues:

1) It’s strange to extract the src tarball and have it be in a 
“build/avro-src-1.9.0” directory.  I’d like to see the “build” level removed.   
Not a big deal, something we can fix in the future.

2) I’m getting some random test failures in java/mapred when run via “build.sh 
docker-test", and not sure why.   If I just run maven outside of docker it runs 
fine.   Also not something to block a release, but a bit strange.

Anyway, +1 as I don’t see either of them as a blocker.

Dan




> On Apr 26, 2019, at 5:53 AM, Driesprong, Fokko  wrote:
> 
> Hi everyone,
> 
> Since the last release of Apache Avro 1.8.2 on May 31, 2017. Two years
> later,
> I'm thrilled to propose the following RC to be released as official Apache
> Avro 1.9.0 release.
> 
> The commit id is 4607730012293fe1e58957760e8f7b5474abd408
> * This corresponds to the tag: release-1.9.0-rc1
> * https://github.com/apache/avro/releases/tag/release-1.9.0-rc1
> 
> The release tarball, signature, and checksums are here:
> * https://dist.apache.org/repos/dist/dev/avro/avro-1.9.0-rc1/
> 
> You can find the KEYS file here:
> * https://dist.apache.org/repos/dist/dev/avro/KEYS
> 
> Binary artifacts for Java are staged in Nexus here:
> *
> https://repository.apache.org/content/groups/staging/org/apache/avro/avro/1.9.0/
> 
> This release includes 270 Jira issues:
> https://issues.apache.org/jira/projects/AVRO/versions/1294
> * Deprecate Joda-Time in favor of Java8 JSR310 and setting it as default
> * Remove support for Hadoop 1.x
> * Move from Jackson 1.x to 2.9
> * Add ZStandard Codec
> * Lots of updates on the dependencies to fix CVE's
> * and many, many more!
> 
> Please download, verify, and test. This vote will remain open for at least
> 72 hours. Given sufficient votes, I would like to close it on or about
> midnight
> on Monday, 29 April 2019.
> 
> [ ] +1 Release this as Apache Avro 1.9.0
> [ ] +0
> [ ] -1 Do not release this because...
> 
> Consider this a +1 (non-binding) from my side:
> * Compiled the new version of Parquet against the Divolte collector and
> Apache Parquet
> 
> Cheers, Fokko Driesprong

-- 
Daniel Kulp
dk...@apache.org  - http://dankulp.com/blog 

Talend Community Coder - http://talend.com 

[jira] [Updated] (AVRO-2381) logical type for fixed incorrectly parsed as disallowed doc attribute

[Nandor Kollar (JIRA)]

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

Nandor Kollar updated AVRO-2381:

Priority: Blocker  (was: Minor)

> logical type for fixed incorrectly parsed as disallowed doc attribute
> -
>
> Key: AVRO-2381
> URL: https://issues.apache.org/jira/browse/AVRO-2381
> Project: Apache Avro
>  Issue Type: Bug
>  Components: ruby
>Affects Versions: 1.9.0
>Reporter: Tim Perkins
>Assignee: Tim Perkins
>Priority: Blocker
> Attachments: avro-2381-patch.txt
>
>




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

Re: [VOTE] Release Apache Avro 1.9.0 RC1

[Tim Perkins]

-1
I found a minor issue for Ruby (patch submitted):
https://issues.apache.org/jira/browse/AVRO-2381

On Fri, Apr 26, 2019 at 5:53 AM Driesprong, Fokko 
wrote:

> Hi everyone,
>
> Since the last release of Apache Avro 1.8.2 on May 31, 2017. Two years
> later,
> I'm thrilled to propose the following RC to be released as official Apache
> Avro 1.9.0 release.
>
> The commit id is 4607730012293fe1e58957760e8f7b5474abd408
> * This corresponds to the tag: release-1.9.0-rc1
> * https://github.com/apache/avro/releases/tag/release-1.9.0-rc1
>
> The release tarball, signature, and checksums are here:
> * https://dist.apache.org/repos/dist/dev/avro/avro-1.9.0-rc1/
>
> You can find the KEYS file here:
> * https://dist.apache.org/repos/dist/dev/avro/KEYS
>
> Binary artifacts for Java are staged in Nexus here:
> *
>
> https://repository.apache.org/content/groups/staging/org/apache/avro/avro/1.9.0/
>
> This release includes 270 Jira issues:
> https://issues.apache.org/jira/projects/AVRO/versions/1294
> * Deprecate Joda-Time in favor of Java8 JSR310 and setting it as default
> * Remove support for Hadoop 1.x
> * Move from Jackson 1.x to 2.9
> * Add ZStandard Codec
> * Lots of updates on the dependencies to fix CVE's
> * and many, many more!
>
> Please download, verify, and test. This vote will remain open for at least
> 72 hours. Given sufficient votes, I would like to close it on or about
> midnight
> on Monday, 29 April 2019.
>
> [ ] +1 Release this as Apache Avro 1.9.0
> [ ] +0
> [ ] -1 Do not release this because...
>
> Consider this a +1 (non-binding) from my side:
> * Compiled the new version of Parquet against the Divolte collector and
> Apache Parquet
>
> Cheers, Fokko Driesprong
>

[jira] [Updated] (AVRO-2381) logical type for fixed incorrectly parsed as disallowed doc attribute

[Tim Perkins (JIRA)]

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

Tim Perkins updated AVRO-2381:
--
Attachment: avro-2381-patch.txt
Status: Patch Available  (was: Open)

> logical type for fixed incorrectly parsed as disallowed doc attribute
> -
>
> Key: AVRO-2381
> URL: https://issues.apache.org/jira/browse/AVRO-2381
> Project: Apache Avro
>  Issue Type: Bug
>  Components: ruby
>Affects Versions: 1.9.0
>Reporter: Tim Perkins
>Assignee: Tim Perkins
>Priority: Minor
> Attachments: avro-2381-patch.txt
>
>




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

[jira] [Created] (AVRO-2381) logical type for fixed incorrectly parsed as disallowed doc attribute

[Tim Perkins (JIRA)]

Tim Perkins created AVRO-2381:
-

 Summary: logical type for fixed incorrectly parsed as disallowed 
doc attribute
 Key: AVRO-2381
 URL: https://issues.apache.org/jira/browse/AVRO-2381
 Project: Apache Avro
  Issue Type: Bug
  Components: ruby
Affects Versions: 1.9.0
Reporter: Tim Perkins
Assignee: Tim Perkins






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

Re: [VOTE] Release Apache Avro 1.9.0 RC1

[Lunjie Jin]

+1

Driesprong, Fokko 于2019年4月26日 周五上午2:53写道：

> Hi everyone,
>
> Since the last release of Apache Avro 1.8.2 on May 31, 2017. Two years
> later,
> I'm thrilled to propose the following RC to be released as official Apache
> Avro 1.9.0 release.
>
> The commit id is 4607730012293fe1e58957760e8f7b5474abd408
> * This corresponds to the tag: release-1.9.0-rc1
> * https://github.com/apache/avro/releases/tag/release-1.9.0-rc1
>
> The release tarball, signature, and checksums are here:
> * https://dist.apache.org/repos/dist/dev/avro/avro-1.9.0-rc1/
>
> You can find the KEYS file here:
> * https://dist.apache.org/repos/dist/dev/avro/KEYS
>
> Binary artifacts for Java are staged in Nexus here:
> *
>
> https://repository.apache.org/content/groups/staging/org/apache/avro/avro/1.9.0/
>
> This release includes 270 Jira issues:
> https://issues.apache.org/jira/projects/AVRO/versions/1294
> * Deprecate Joda-Time in favor of Java8 JSR310 and setting it as default
> * Remove support for Hadoop 1.x
> * Move from Jackson 1.x to 2.9
> * Add ZStandard Codec
> * Lots of updates on the dependencies to fix CVE's
> * and many, many more!
>
> Please download, verify, and test. This vote will remain open for at least
> 72 hours. Given sufficient votes, I would like to close it on or about
> midnight
> on Monday, 29 April 2019.
>
> [ ] +1 Release this as Apache Avro 1.9.0
> [ ] +0
> [ ] -1 Do not release this because...
>
> Consider this a +1 (non-binding) from my side:
> * Compiled the new version of Parquet against the Divolte collector and
> Apache Parquet
>
> Cheers, Fokko Driesprong
>

[VOTE] Release Apache Avro 1.9.0 RC1

[Driesprong, Fokko]

Hi everyone,

Since the last release of Apache Avro 1.8.2 on May 31, 2017. Two years
later,
I'm thrilled to propose the following RC to be released as official Apache
Avro 1.9.0 release.

The commit id is 4607730012293fe1e58957760e8f7b5474abd408
* This corresponds to the tag: release-1.9.0-rc1
* https://github.com/apache/avro/releases/tag/release-1.9.0-rc1

The release tarball, signature, and checksums are here:
* https://dist.apache.org/repos/dist/dev/avro/avro-1.9.0-rc1/

You can find the KEYS file here:
* https://dist.apache.org/repos/dist/dev/avro/KEYS

Binary artifacts for Java are staged in Nexus here:
*
https://repository.apache.org/content/groups/staging/org/apache/avro/avro/1.9.0/

This release includes 270 Jira issues:
https://issues.apache.org/jira/projects/AVRO/versions/1294
* Deprecate Joda-Time in favor of Java8 JSR310 and setting it as default
* Remove support for Hadoop 1.x
* Move from Jackson 1.x to 2.9
* Add ZStandard Codec
* Lots of updates on the dependencies to fix CVE's
* and many, many more!

Please download, verify, and test. This vote will remain open for at least
72 hours. Given sufficient votes, I would like to close it on or about
midnight
on Monday, 29 April 2019.

[ ] +1 Release this as Apache Avro 1.9.0
[ ] +0
[ ] -1 Do not release this because...

Consider this a +1 (non-binding) from my side:
* Compiled the new version of Parquet against the Divolte collector and
Apache Parquet

Cheers, Fokko Driesprong

[jira] [Updated] (AVRO-2247) Improve Java reading performance with a new reader

[Fokko Driesprong (JIRA)]

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

Fokko Driesprong updated AVRO-2247:
---
Fix Version/s: (was: 1.9.0)
   1.10.0

> Improve Java reading performance with a new reader
> --
>
> Key: AVRO-2247
> URL: https://issues.apache.org/jira/browse/AVRO-2247
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: Martin Jubelgas
>Priority: Major
> Fix For: 1.10.0
>
> Attachments: Perf-Comparison.md
>
>
> Complementary to AVRO-2090, I have been working on decoding of Avro objects 
> in Java and am suggesting a new implementation of a DatumReader that improves 
> read performance for both generic and specific records by approximately 20% 
> (and even more in cases of nested objects with defaults, a case I encounter a 
> lot in practical use).
> Key concept is to create a detailed execution plan once at DatumReader. This 
> execution plan contains all required defaulting/lookup values so they need 
> not be looked up during object traversal while reading.
> The reader implementation can be enabled and disabled per GenericData 
> instance. The system default is set via the system variable 
> "org.apache.avro.fastread" (defaults to "false").
> Attached a performance comparison of the existing implementation with the 
> proposed one. Will open a pull request with respective code in a bit (not 
> including interoperability with the optimizations of AVRO-2090 yet). Please 
> let me know your opinion of whether this is worth pursuing further.
>  



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

[jira] [Updated] (AVRO-1467) Schema resolution does not check record names

[Fokko Driesprong (JIRA)]

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

Fokko Driesprong updated AVRO-1467:
---
Fix Version/s: (was: 1.9.0)
   1.10.0

> Schema resolution does not check record names
> -
>
> Key: AVRO-1467
> URL: https://issues.apache.org/jira/browse/AVRO-1467
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.7.6
>Reporter: Jim Pivarski
>Priority: Major
> Fix For: 1.10.0
>
>
> According to http://avro.apache.org/docs/1.7.6/spec.html#Schema+Resolution , 
> writer and reader schemae should be considered compatible if they (1) have 
> the same name and (2) the reader requests a subset of the writer's fields 
> with compatible types.  In the Java version, I find that the structure of the 
> fields is checked but the name is _not_ checked.  (It's too permissive; acts 
> like a structural type check, rather than structural and nominal.)
> Here's a demonstration (in the Scala REPL to allow for experimentation; 
> launch with "scala -cp avro-tools-1.7.6.jar" to get all the classes).  The 
> following writes a small, valid Avro data file:
> {code:java}
> import org.apache.avro.file.DataFileReader
> import org.apache.avro.file.DataFileWriter
> import org.apache.avro.generic.GenericData
> import org.apache.avro.generic.GenericDatumReader
> import org.apache.avro.generic.GenericDatumWriter
> import org.apache.avro.generic.GenericRecord
> import org.apache.avro.io.DatumReader
> import org.apache.avro.io.DatumWriter
> import org.apache.avro.Schema
> val parser = new Schema.Parser
> // The name is different but the fields are the same.
> val writerSchema = parser.parse("""{"type": "record", "name": "Writer", 
> "fields": [{"name": "one", "type": "int"}, {"name": "two", "type": 
> "string"}]}""")
> val readerSchema = parser.parse("""{"type": "record", "name": "Reader", 
> "fields": [{"name": "one", "type": "int"}, {"name": "two", "type": 
> "string"}]}""")
> def makeRecord(one: Int, two: String): GenericRecord = {
>   val out = new GenericData.Record(writerSchema)
>   out.put("one", one)
>   out.put("two", two)
>   out
> }
> val datumWriter = new GenericDatumWriter[GenericRecord](writerSchema)
> val dataFileWriter = new DataFileWriter[GenericRecord](datumWriter)
> dataFileWriter.create(writerSchema, new java.io.File("/tmp/test.avro"))
> dataFileWriter.append(makeRecord(1, "one"))
> dataFileWriter.append(makeRecord(2, "two"))
> dataFileWriter.append(makeRecord(3, "three"))
> dataFileWriter.close()
> {code}
> Looking at the output with "hexdump -C /tmp/test.avro", we see that the 
> writer schema is embedded in the file, and the record's name is "Writer".  To 
> read it back:
> {code:java}
> val datumReader = new GenericDatumReader[GenericRecord](writerSchema, 
> readerSchema)
> val dataFileReader = new DataFileReader[GenericRecord](new 
> java.io.File("/tmp/test.avro"), datumReader)
> while (dataFileReader.hasNext) {
>   val in = dataFileReader.next()
>   println(in, in.getSchema)
> }
> {code}
> The problem is that the above is successful, even though I'm requesting a 
> record with name "Reader".
> If I make structurally incompatible records, for instance by writing with 
> "Writer.two" being an integer and "Reader.two" being a string, it fails to 
> read with org.apache.avro.AvroTypeException (as it should).  If I try the 
> above test with an enum type or a fixed type, it _does_ require the writer 
> and reader names to match: record is the only named type for which the name 
> is ignored during schema resolution.
> We're supposed to use aliases to explicitly declare which structurally 
> compatible writer-reader combinations to accept.  Because of the above bug, 
> differently named records are accepted regardless of their aliases, but enums 
> and fixed types are not accepted, even if they have the right aliases.  This 
> may be a separate bug, or it may be related to the above.
> To make sure that I'm correctly understanding the specification, I tried 
> exactly the same thing in the Python version:
> {code:python}
> import avro.schema
> from avro.datafile import DataFileReader, DataFileWriter
> from avro.io import DatumReader, DatumWriter
> writerSchema = avro.schema.parse('{"type": "record", "name": "Writer", 
> "fields": [{"name": "one", "type": "int"}, {"name": "two", "type": 
> "string"}]}')
> readerSchema = avro.schema.parse('{"type": "record", "name": "Reader", 
> "fields": [{"name": "one", "type": "int"}, {"name": "two", "type": 
> "string"}]}')
> writer = DataFileWriter(open("/tmp/test2.avro", "w"), DatumWriter(), 
> writerSchema)
> writer.append({"one": 1, "two": "one"})
> writer.append({"one": 2, "two": "two"})
> writer.append({"one": 3, "two": "three"})
> writer.close()
> reader = 

[jira] [Updated] (AVRO-1543) libboost_zlib library is not detected but is required

[Fokko Driesprong (JIRA)]

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

Fokko Driesprong updated AVRO-1543:
---
Fix Version/s: (was: 1.9.0)
   1.10.0

> libboost_zlib library is not detected but is required
> -
>
> Key: AVRO-1543
> URL: https://issues.apache.org/jira/browse/AVRO-1543
> Project: Apache Avro
>  Issue Type: Bug
>  Components: c++
>Affects Versions: 1.7.6
> Environment: Windows?
>Reporter: Sean Middleditch
>Assignee: Thiruvalluvan M. G.
>Priority: Major
> Fix For: 1.10.0
>
>
> Standard builds of Boost with the iostreams library and zlib support build 
> two separate libraries, libboost_iostreams and libboost_zlib. Avro is 
> properly setup to detect and link in the former but not the later, meaning 
> that Avro cannot be build out of the box without customizing either the Boost 
> build or Avro's CMakeLists.txt.
> Another alternative change may be to remove Avro's hard requirement on zlib 
> support in Boost's iostreams library, especially as stand-alone Boost builds 
> will not include zlib support. Avro could either require its own flag for 
> zlib support (being explicit is good, so this would be good) or detect if 
> Boost was compiled with zlib support during CMake generation time. If Avro 
> does not do either of these, it needs to be updated to link in libboost_zlib.



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

[jira] [Updated] (AVRO-1521) Inconsistent behavior of Perl API with 'boolean' type

[Fokko Driesprong (JIRA)]

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

Fokko Driesprong updated AVRO-1521:
---
Fix Version/s: (was: 1.9.0)
   1.10.0

> Inconsistent behavior of Perl API with 'boolean' type
> -
>
> Key: AVRO-1521
> URL: https://issues.apache.org/jira/browse/AVRO-1521
> Project: Apache Avro
>  Issue Type: Bug
>  Components: perl
>Reporter: John Karp
>Assignee: John Karp
>Priority: Major
> Fix For: 1.10.0
>
>
> The perl boolean serialization code in BinaryEncoder.pm encodes anything 
> false to perl, such as 0, '0', '', () and undef, as false, and anything true 
> to perl, which is literally everything else, as true.
> Inconsistent with the above serialization, the code used in Schema.pm to 
> determine which union branch to use, is checking for boolean-ness with:
> {noformat}
> m{yes|no|y|n|t|f|true|false}i
> {noformat}
> meaning only those particular strings are considered booleans.
> So all those values, including 'no' 'n' 'f' and 'false', still get serialized 
> to true.
> We could just standardize on one of the two and use it consistently. But 
> neither works that well in unions, because unless you put the boolean type 
> last in the union definition, a wide variety of data will be downcast to 
> boolean type.
> Perl has no built-in or standardized boolean type, so there's no solution 
> like we have in the other language Avro APIs. But we could do as the perl 
> JSON module does, and define objects for true and false.



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

[jira] [Updated] (AVRO-1235) Avro does not handle corrupt records

[Fokko Driesprong (JIRA)]

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

Fokko Driesprong updated AVRO-1235:
---
Fix Version/s: (was: 1.9.0)
   1.10.0

> Avro does not handle corrupt records
> 
>
> Key: AVRO-1235
> URL: https://issues.apache.org/jira/browse/AVRO-1235
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.7.3
>Reporter: Santhosh Srinivasan
>Priority: Critical
> Fix For: 1.10.0
>
>
> As per PIG-3015 (see 
> https://issues.apache.org/jira/browse/PIG-3015?focusedCommentId=13547011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13547011),
>  Avro is not handling corrupt records.
> This could be a serious issue.



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