[jira] [Commented] (PARQUET-1950) Define core features / compliance level

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

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

ASF GitHub Bot commented on PARQUET-1950:
-----------------------------------------

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


   Make sure you have checked _all_ steps below.
   
   ### Jira
   
   - [x] My PR addresses the following [PARQUET-1950](https://issues.apache.org/jira/browse/PARQUET-1950) 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).
   
   ### Commits
   
   - [x] 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
   
   - [x] 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
   
   -----
   
   The whole document is up to discussion but the parts which are marked with a **?** or **TODO** are the ones where I don't have a hard opinion. Feel free to add any comment about content or wording.


----------------------------------------------------------------
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:
users@infra.apache.org


> Define core features / compliance level
> ---------------------------------------
>
>                 Key: PARQUET-1950
>                 URL: https://issues.apache.org/jira/browse/PARQUET-1950
>             Project: Parquet
>          Issue Type: New Feature
>          Components: parquet-format
>            Reporter: Gabor Szadovszky
>            Assignee: Gabor Szadovszky
>            Priority: Major
>
> Parquet format is getting more and more features while the different implementations cannot keep the pace and left behind with some features implemented and some are not. In many cases it is also not clear if the related feature is mature enough to be used widely or more an experimental one.
> These are huge issues that makes hard ensure interoperability between the different implementations.
> The following idea came up in a [discussion|https://lists.apache.org/thread.html/rde5cba8443487bccd47593ddf5dfb39f69c729d260165cb936a1a289%40%3Cdev.parquet.apache.org%3E]. Create a now document in the parquet-format repository that lists the "core features". This document is versioned by the parquet-format releases. This way a certain version of "core features" defines a level of compatibility between the different implementations. This version number can be written to a new field (e.g. complianceLevel) in the footer. If an implementation writes a file with a version in the field it must implement all the related "core features" (read and write) and must not use any other features at write because it makes the data unreadable by another implementation if only the same level of "core features" are implemented.
> For example if we have encoding A listed in the version 1 "core features" but encoding B is not then at "complianceLevel = 1" we can use encoding A but we cannot use encoding B because it would make the related data unreadable.



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