[GitHub] [parquet-mr] shangxinli commented on pull request #901: PARQUET-2037: Write INT96 with parquet-avro

2021-05-04 Thread GitBox 


shangxinli commented on pull request #901:
URL: https://github.com/apache/parquet-mr/pull/901#issuecomment-832398022


   In the ticket, you mentioned there are two ways to solve this issue. I see 
you implemented it using the 2nd way. I wonder what is the reason behind it?  I 
am not in favor of one over the other, just want to know what are the pros and 
cons for each.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[GitHub] [parquet-mr] shangxinli commented on pull request #902: PARQUET-1633 Fix integer overflow

2021-05-04 Thread GitBox 


shangxinli commented on pull request #902:
URL: https://github.com/apache/parquet-mr/pull/902#issuecomment-832290027


   Can you come up with a unit test? 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[jira] [Commented] (PARQUET-1798) [C++] Review logic around automatic assignment of field_id's

2021-05-04 Thread Weston Pace (Jira) 


[ 
https://issues.apache.org/jira/browse/PARQUET-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339290#comment-17339290
 ] 

Weston Pace commented on PARQUET-1798:
--

Is there something wrong with the generation algorithm?  Or is it more that 
there is no way to override the generation algorithm to use existing field IDs?

For example, it would be pretty straightforward to use the existing algorithm 
when going from Arrow->Parquet if no field id exists in the Arrow metadata.  On 
the other hand, the field ID algorithm could be updated so a column name (or 
column path for nested columns) will always generate the same ID (unless there 
are multiple columns with the same name).

Does the following make sense (independent of which generation algorithm we 
use):

 

Parquet -> Arrow

 * If field_id is set use that

 * If field_id is not set use generation algorithm

Arrow -> Parquet

 * If field_id is set use that

 * If field_id is not set use generation algorithm

 

That should be round-trippable since all subsequent read/writes after the first 
re-use existing field_ids.

> [C++] Review logic around automatic assignment of field_id's
> 
>
> Key: PARQUET-1798
> URL: https://issues.apache.org/jira/browse/PARQUET-1798
> Project: Parquet
>  Issue Type: Improvement
>  Components: parquet-cpp
>Reporter: Wes McKinney
>Priority: Major
> Fix For: cpp-4.0.0
>
>
> At schema deserialization (from Thrift) time, we are assigning a default 
> field_id to the Schema node based on a depth-first ordering of notes. This 
> means that a round trip (load, then write) will cause field_id's to be 
> written that weren't there before. I'm not sure this is the desired behavior.
> We should examine this in more detail and possible change it. See also 
> discussion in ARROW-7080 https://github.com/apache/arrow/pull/6408



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (PARQUET-1633) Integer overflow in ParquetFileReader.ConsecutiveChunkList

2021-05-04 Thread ASF GitHub Bot (Jira) 


[ 
https://issues.apache.org/jira/browse/PARQUET-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17338998#comment-17338998
 ] 

ASF GitHub Bot commented on PARQUET-1633:
-

eadwright commented on a change in pull request #902:
URL: https://github.com/apache/parquet-mr/pull/902#discussion_r625792180



##
File path: 
parquet-hadoop/src/main/java/org/apache/parquet/hadoop/ParquetFileReader.java
##
@@ -1464,7 +1464,7 @@ protected PageHeader readPageHeader(BlockCipher.Decryptor 
blockDecryptor, byte[]
  */
 private void verifyCrc(int referenceCrc, byte[] bytes, String 
exceptionMsg) {
   crc.reset();
-  crc.update(bytes);
+  crc.update(bytes, 0, bytes.length);

Review comment:
   Changed to adopt a Java 8 API, to be consistent with the pom




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Integer overflow in ParquetFileReader.ConsecutiveChunkList
> --
>
> Key: PARQUET-1633
> URL: https://issues.apache.org/jira/browse/PARQUET-1633
> Project: Parquet
>  Issue Type: Bug
>  Components: parquet-mr
>Affects Versions: 1.10.1
>Reporter: Ivan Sadikov
>Priority: Major
>
> When reading a large Parquet file (2.8GB), I encounter the following 
> exception:
> {code:java}
> Caused by: org.apache.parquet.io.ParquetDecodingException: Can not read value 
> at 0 in block -1 in file 
> dbfs:/user/hive/warehouse/demo.db/test_table/part-00014-tid-1888470069989036737-593c82a4-528b-4975-8de0-5bcbc5e9827d-10856-1-c000.snappy.parquet
> at 
> org.apache.parquet.hadoop.InternalParquetRecordReader.nextKeyValue(InternalParquetRecordReader.java:251)
> at 
> org.apache.parquet.hadoop.ParquetRecordReader.nextKeyValue(ParquetRecordReader.java:207)
> at 
> org.apache.spark.sql.execution.datasources.RecordReaderIterator.hasNext(RecordReaderIterator.scala:40)
> at 
> org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1$$anon$2.getNext(FileScanRDD.scala:228)
> ... 14 more
> Caused by: java.lang.IllegalArgumentException: Illegal Capacity: -212
> at java.util.ArrayList.(ArrayList.java:157)
> at 
> org.apache.parquet.hadoop.ParquetFileReader$ConsecutiveChunkList.readAll(ParquetFileReader.java:1169){code}
>  
> The file metadata is:
>  * block 1 (3 columns)
>  ** rowCount: 110,100
>  ** totalByteSize: 348,492,072
>  ** compressedSize: 165,689,649
>  * block 2 (3 columns)
>  ** rowCount: 90,054
>  ** totalByteSize: 3,243,165,541
>  ** compressedSize: 2,509,579,966
>  * block 3 (3 columns)
>  ** rowCount: 105,119
>  ** totalByteSize: 350,901,693
>  ** compressedSize: 144,952,177
>  * block 4 (3 columns)
>  ** rowCount: 48,741
>  ** totalByteSize: 1,275,995
>  ** compressedSize: 914,205
> I don't have the code to reproduce the issue, unfortunately; however, I 
> looked at the code and it seems that integer {{length}} field in 
> ConsecutiveChunkList overflows, which results in negative capacity for array 
> list in {{readAll}} method:
> {code:java}
> int fullAllocations = length / options.getMaxAllocationSize();
> int lastAllocationSize = length % options.getMaxAllocationSize();
>   
> int numAllocations = fullAllocations + (lastAllocationSize > 0 ? 1 : 0);
> List buffers = new ArrayList<>(numAllocations);{code}
>  
> This is caused by cast to integer in {{readNextRowGroup}} method in 
> ParquetFileReader:
> {code:java}
> currentChunks.addChunk(new ChunkDescriptor(columnDescriptor, mc, startingPos, 
> (int)mc.getTotalSize()));
> {code}
> which overflows when total size of the column is larger than 
> Integer.MAX_VALUE.
> I would appreciate if you could help addressing the issue. Thanks!
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [parquet-mr] eadwright commented on a change in pull request #902: PARQUET-1633 Fix integer overflow

2021-05-04 Thread GitBox 


eadwright commented on a change in pull request #902:
URL: https://github.com/apache/parquet-mr/pull/902#discussion_r625792180



##
File path: 
parquet-hadoop/src/main/java/org/apache/parquet/hadoop/ParquetFileReader.java
##
@@ -1464,7 +1464,7 @@ protected PageHeader readPageHeader(BlockCipher.Decryptor 
blockDecryptor, byte[]
  */
 private void verifyCrc(int referenceCrc, byte[] bytes, String 
exceptionMsg) {
   crc.reset();
-  crc.update(bytes);
+  crc.update(bytes, 0, bytes.length);

Review comment:
   Changed to adopt a Java 8 API, to be consistent with the pom




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[jira] [Commented] (PARQUET-1633) Integer overflow in ParquetFileReader.ConsecutiveChunkList

2021-05-04 Thread ASF GitHub Bot (Jira) 


[ 
https://issues.apache.org/jira/browse/PARQUET-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17338988#comment-17338988
 ] 

ASF GitHub Bot commented on PARQUET-1633:
-

eadwright opened a new pull request #902:
URL: https://github.com/apache/parquet-mr/pull/902


   This PR addresses this issue: 
https://issues.apache.org/jira/browse/PARQUET-1633
   
   I have not added unit tests, as to check overflow conditions I would need 
test data over 2GB in size (on disk, compressed), considerably larger in-memory 
and thus requiring significant CI resources.
   
   The issue was using an `int` for length field, which for parquet files with 
very large `row_group_size` (row groups over 2GB) would cause silent integer 
overflow, manifesting itself as negative length and an attempt to create an 
ArrayList with negative length.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Integer overflow in ParquetFileReader.ConsecutiveChunkList
> --
>
> Key: PARQUET-1633
> URL: https://issues.apache.org/jira/browse/PARQUET-1633
> Project: Parquet
>  Issue Type: Bug
>  Components: parquet-mr
>Affects Versions: 1.10.1
>Reporter: Ivan Sadikov
>Priority: Major
>
> When reading a large Parquet file (2.8GB), I encounter the following 
> exception:
> {code:java}
> Caused by: org.apache.parquet.io.ParquetDecodingException: Can not read value 
> at 0 in block -1 in file 
> dbfs:/user/hive/warehouse/demo.db/test_table/part-00014-tid-1888470069989036737-593c82a4-528b-4975-8de0-5bcbc5e9827d-10856-1-c000.snappy.parquet
> at 
> org.apache.parquet.hadoop.InternalParquetRecordReader.nextKeyValue(InternalParquetRecordReader.java:251)
> at 
> org.apache.parquet.hadoop.ParquetRecordReader.nextKeyValue(ParquetRecordReader.java:207)
> at 
> org.apache.spark.sql.execution.datasources.RecordReaderIterator.hasNext(RecordReaderIterator.scala:40)
> at 
> org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1$$anon$2.getNext(FileScanRDD.scala:228)
> ... 14 more
> Caused by: java.lang.IllegalArgumentException: Illegal Capacity: -212
> at java.util.ArrayList.(ArrayList.java:157)
> at 
> org.apache.parquet.hadoop.ParquetFileReader$ConsecutiveChunkList.readAll(ParquetFileReader.java:1169){code}
>  
> The file metadata is:
>  * block 1 (3 columns)
>  ** rowCount: 110,100
>  ** totalByteSize: 348,492,072
>  ** compressedSize: 165,689,649
>  * block 2 (3 columns)
>  ** rowCount: 90,054
>  ** totalByteSize: 3,243,165,541
>  ** compressedSize: 2,509,579,966
>  * block 3 (3 columns)
>  ** rowCount: 105,119
>  ** totalByteSize: 350,901,693
>  ** compressedSize: 144,952,177
>  * block 4 (3 columns)
>  ** rowCount: 48,741
>  ** totalByteSize: 1,275,995
>  ** compressedSize: 914,205
> I don't have the code to reproduce the issue, unfortunately; however, I 
> looked at the code and it seems that integer {{length}} field in 
> ConsecutiveChunkList overflows, which results in negative capacity for array 
> list in {{readAll}} method:
> {code:java}
> int fullAllocations = length / options.getMaxAllocationSize();
> int lastAllocationSize = length % options.getMaxAllocationSize();
>   
> int numAllocations = fullAllocations + (lastAllocationSize > 0 ? 1 : 0);
> List buffers = new ArrayList<>(numAllocations);{code}
>  
> This is caused by cast to integer in {{readNextRowGroup}} method in 
> ParquetFileReader:
> {code:java}
> currentChunks.addChunk(new ChunkDescriptor(columnDescriptor, mc, startingPos, 
> (int)mc.getTotalSize()));
> {code}
> which overflows when total size of the column is larger than 
> Integer.MAX_VALUE.
> I would appreciate if you could help addressing the issue. Thanks!
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [parquet-mr] eadwright opened a new pull request #902: PARQUET-1633 Fix integer overflow

2021-05-04 Thread GitBox 


eadwright opened a new pull request #902:
URL: https://github.com/apache/parquet-mr/pull/902


   This PR addresses this issue: 
https://issues.apache.org/jira/browse/PARQUET-1633
   
   I have not added unit tests, as to check overflow conditions I would need 
test data over 2GB in size (on disk, compressed), considerably larger in-memory 
and thus requiring significant CI resources.
   
   The issue was using an `int` for length field, which for parquet files with 
very large `row_group_size` (row groups over 2GB) would cause silent integer 
overflow, manifesting itself as negative length and an attempt to create an 
ArrayList with negative length.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

Re: [parquet-mr] Support writing INT96 type by parquet-avro

2021-05-04 Thread Gabor Szadovszky 
I've created PARQUET-2037
 about this topic. Also
created a potential implementation: #901

Any reviews/comments are welcomed.

On Tue, Apr 20, 2021 at 4:48 PM Gabor Szadovszky  wrote:

> Hi everyone,
>
> We have faced a customer issue that we need to write INT96 values using
> parquet-avro. I don't have too much experience in parquet-avro so I am
> curious about your opinions.
>
> After PARQUET-1928 we are able to read INT96 values into Avro FIXED values
> by using the configuration "parquet.avro.readInt96AsFixed". Now we need a
> similar option where we can write the FIXED values into the original INT96
> values. There are two problems I can see with this.
> 1. INT96 is deprecated for a while now. Previously we did not want to
> implement anything for additional support of INT96. What are your feelings
> on this?
> 2. How can we distinguish the "original" FIXED values from the ones
> created from INT96 values? Of course we only need to convert FIXED values
> that have the length of 12bytes but I don't think it is enough.
>
> Thanks a lot,
> Gabor
>

[jira] [Commented] (PARQUET-2037) Write INT96 with parquet-avro

2021-05-04 Thread ASF GitHub Bot (Jira) 


[ 
https://issues.apache.org/jira/browse/PARQUET-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17338958#comment-17338958
 ] 

ASF GitHub Bot commented on PARQUET-2037:
-

gszadovszky opened a new pull request #901:
URL: https://github.com/apache/parquet-mr/pull/901


   Make sure you have checked _all_ steps below.
   
   ### Jira
   
   - [ ] My PR addresses the following [Parquet 
Jira](https://issues.apache.org/jira/browse/PARQUET/) issues and references 
them in the PR title. For example, "PARQUET-1234: My Parquet PR"
 - https://issues.apache.org/jira/browse/PARQUET-XXX
 - In case you are adding a dependency, check if the license complies with 
the [ASF 3rd Party License 
Policy](https://www.apache.org/legal/resolved.html#category-x).
   
   ### Tests
   
   - [ ] My PR adds the following unit tests __OR__ does not need testing for 
this extremely good reason:
   
   ### Commits
   
   - [ ] My commits all reference Jira issues in their subject lines. In 
addition, my commits follow the guidelines from "[How to write a good git 
commit message](http://chris.beams.io/posts/git-commit/)":
 1. Subject is separated from body by a blank line
 1. Subject is limited to 50 characters (not including Jira issue reference)
 1. Subject does not end with a period
 1. Subject uses the imperative mood ("add", not "adding")
 1. Body wraps at 72 characters
 1. Body explains "what" and "why", not "how"
   
   ### Documentation
   
   - [ ] In case of new functionality, my PR adds documentation that describes 
how to use it.
 - All the public functions and the classes in the PR contain Javadoc that 
explain what it does
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Write INT96 with parquet-avro
> -
>
> Key: PARQUET-2037
> URL: https://issues.apache.org/jira/browse/PARQUET-2037
> Project: Parquet
>  Issue Type: Improvement
>  Components: parquet-avro, parquet-mr
>Reporter: Gabor Szadovszky
>Assignee: Gabor Szadovszky
>Priority: Major
>
> This jira is about the write path of PARQUET-1928. 
> The issue here is how to identify an Avro FIXED type that was an INT96 
> before. Of course, this feature would be behind a configuration flag 
> similarly to PARQUET-1928. But even with this flag it is not obvious to 
> differentiate a "simple" FIXED[12] byte from one that was an INT96 before.
> Two options to solve this issue:
> * Write the doc field of the avro schema that the FIXED value was an INT96.
> * Instead of implementing a configuration flag let the user specify the names 
> of the columns to be converted to INT96 via the configuration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [parquet-mr] gszadovszky opened a new pull request #901: PARQUET-2037: Write INT96 with parquet-avro

2021-05-04 Thread GitBox 


gszadovszky opened a new pull request #901:
URL: https://github.com/apache/parquet-mr/pull/901


   Make sure you have checked _all_ steps below.
   
   ### Jira
   
   - [ ] My PR addresses the following [Parquet 
Jira](https://issues.apache.org/jira/browse/PARQUET/) issues and references 
them in the PR title. For example, "PARQUET-1234: My Parquet PR"
 - https://issues.apache.org/jira/browse/PARQUET-XXX
 - In case you are adding a dependency, check if the license complies with 
the [ASF 3rd Party License 
Policy](https://www.apache.org/legal/resolved.html#category-x).
   
   ### Tests
   
   - [ ] My PR adds the following unit tests __OR__ does not need testing for 
this extremely good reason:
   
   ### Commits
   
   - [ ] My commits all reference Jira issues in their subject lines. In 
addition, my commits follow the guidelines from "[How to write a good git 
commit message](http://chris.beams.io/posts/git-commit/)":
 1. Subject is separated from body by a blank line
 1. Subject is limited to 50 characters (not including Jira issue reference)
 1. Subject does not end with a period
 1. Subject uses the imperative mood ("add", not "adding")
 1. Body wraps at 72 characters
 1. Body explains "what" and "why", not "how"
   
   ### Documentation
   
   - [ ] In case of new functionality, my PR adds documentation that describes 
how to use it.
 - All the public functions and the classes in the PR contain Javadoc that 
explain what it does
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[jira] [Commented] (PARQUET-2038) Upgrade Jackson version used in parquet encryption

2021-05-04 Thread ASF GitHub Bot (Jira) 


[ 
https://issues.apache.org/jira/browse/PARQUET-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17338954#comment-17338954
 ] 

ASF GitHub Bot commented on PARQUET-2038:
-

gszadovszky merged pull request #898:
URL: https://github.com/apache/parquet-mr/pull/898


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Upgrade Jackson version used in parquet encryption
> --
>
> Key: PARQUET-2038
> URL: https://issues.apache.org/jira/browse/PARQUET-2038
> Project: Parquet
>  Issue Type: Improvement
>  Components: parquet-mr
>Affects Versions: 1.12.0
>Reporter: Maya Anderson
>Assignee: Maya Anderson
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (PARQUET-2038) Upgrade Jackson version used in parquet encryption

2021-05-04 Thread Gabor Szadovszky (Jira) 


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

Gabor Szadovszky resolved PARQUET-2038.
---
Resolution: Fixed

> Upgrade Jackson version used in parquet encryption
> --
>
> Key: PARQUET-2038
> URL: https://issues.apache.org/jira/browse/PARQUET-2038
> Project: Parquet
>  Issue Type: Improvement
>  Components: parquet-mr
>Affects Versions: 1.12.0
>Reporter: Maya Anderson
>Assignee: Maya Anderson
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [parquet-mr] gszadovszky merged pull request #898: PARQUET-2038: Upgrade Jackson version used in parquet encryption.

2021-05-04 Thread GitBox 


gszadovszky merged pull request #898:
URL: https://github.com/apache/parquet-mr/pull/898


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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

[jira] [Created] (PARQUET-2043) Fail build for used but not declared direct dependencies

2021-05-04 Thread Gabor Szadovszky (Jira) 
Gabor Szadovszky created PARQUET-2043:
-

 Summary: Fail build for used but not declared direct dependencies
 Key: PARQUET-2043
 URL: https://issues.apache.org/jira/browse/PARQUET-2043
 Project: Parquet
  Issue Type: Improvement
  Components: parquet-mr
Reporter: Gabor Szadovszky


It is always a good practice to specify all the dependencies directly used 
(classes are imported from) by our modules. We have a couple of issues where 
classes are imported from transitive dependencies. It makes hard to validate 
the actual dependency tree and also may result in using wrong versions of 
classes (see PARQUET-2038 for example).

It would be good to enforce to reference such dependencies directly in the 
module poms. The [maven-dependency-plugin analyze-only 
goal|http://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html]
 can be used for this purpose.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PARQUET-1230) CLI tools for encrypted files

2021-05-04 Thread Gidon Gershinsky (Jira) 


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

Gidon Gershinsky updated PARQUET-1230:
--
  Component/s: parquet-mr
Affects Version/s: 1.12.0

> CLI tools for encrypted files
> -
>
> Key: PARQUET-1230
> URL: https://issues.apache.org/jira/browse/PARQUET-1230
> Project: Parquet
>  Issue Type: New Feature
>  Components: parquet-mr
>Affects Versions: 1.12.0
>Reporter: Gidon Gershinsky
>Assignee: Gidon Gershinsky
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PARQUET-1230) CLI tools for encrypted files

2021-05-04 Thread Gidon Gershinsky (Jira) 


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

Gidon Gershinsky updated PARQUET-1230:
--
Parent: (was: PARQUET-1178)
Issue Type: New Feature  (was: Sub-task)

> CLI tools for encrypted files
> -
>
> Key: PARQUET-1230
> URL: https://issues.apache.org/jira/browse/PARQUET-1230
> Project: Parquet
>  Issue Type: New Feature
>Reporter: Gidon Gershinsky
>Assignee: Gidon Gershinsky
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (PARQUET-2038) Upgrade Jackson version used in parquet encryption

2021-05-04 Thread ASF GitHub Bot (Jira) 


[ 
https://issues.apache.org/jira/browse/PARQUET-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17338803#comment-17338803
 ] 

ASF GitHub Bot commented on PARQUET-2038:
-

andersonm-ibm commented on pull request #898:
URL: https://github.com/apache/parquet-mr/pull/898#issuecomment-831731317


   Hi @gszadovszky , could you please take a look at this? 
   Thank you.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Upgrade Jackson version used in parquet encryption
> --
>
> Key: PARQUET-2038
> URL: https://issues.apache.org/jira/browse/PARQUET-2038
> Project: Parquet
>  Issue Type: Improvement
>  Components: parquet-mr
>Affects Versions: 1.12.0
>Reporter: Maya Anderson
>Assignee: Maya Anderson
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [parquet-mr] andersonm-ibm commented on pull request #898: PARQUET-2038: Upgrade Jackson version used in parquet encryption.

2021-05-04 Thread GitBox 


andersonm-ibm commented on pull request #898:
URL: https://github.com/apache/parquet-mr/pull/898#issuecomment-831731317


   Hi @gszadovszky , could you please take a look at this? 
   Thank you.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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