You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "Joris Van den Bossche (Jira)" <ji...@apache.org> on 2022/02/17 09:21:00 UTC

[jira] [Created] (ARROW-15711) [C++][Parquet] Extension types with nanosecond timestamp resolution don't roundtrip

Joris Van den Bossche created ARROW-15711:
---------------------------------------------

             Summary: [C++][Parquet] Extension types with nanosecond timestamp resolution don't roundtrip
                 Key: ARROW-15711
                 URL: https://issues.apache.org/jira/browse/ARROW-15711
             Project: Apache Arrow
          Issue Type: Bug
          Components: C++, Parquet
            Reporter: Joris Van den Bossche


Example code:

{code:python}
import pyarrow as pa
import pyarrow.parquet as pq

class MyTimestampType(pa.PyExtensionType):

    def __init__(self):
        pa.PyExtensionType.__init__(self, pa.timestamp("ns"))

    def __reduce__(self):
        return MyTimestampType, ()


arr = MyTimestampType().wrap_array(pa.array([1000, 2000, 3000], pa.timestamp("ns")))
table = pa.table({"col": arr})
{code}

{code}
>>> table.schema
col: extension<arrow.py_extension_type<MyTimestampType>>

>>> pq.write_table(table, "test_parquet_extension_type_timestamp_ns.parquet")
>>> result = pq.read_table("test_parquet_extension_type_timestamp_ns.parquet")
>>> result.schema
col: timestamp[us]
{code}

The reason for this is because we only restore the extension type if the inferred storage type (inferred from parquet + after applying any updates based on the Arrow schema) exactly equals the original storage type (as stored in the Arrow schema):

https://github.com/apache/arrow/blob/afaa92e7e4289d6e4f302cc91810368794e8092b/cpp/src/parquet/arrow/schema.cc#L973-L977

And, with the default options, a timestamp with nanosecond resolution gets stored as microsecond resolution in Parquet, and that is something we do not restore when updating the read types based on the stored Arrow schema (eg we do add a timezone, but we don't change the resolution).

An additional issue is that _if_ you loose the extension type, the field metadata about the extension type are also lost. I think that if we cannot restore the extension type, we should at least try to keep the ARROW:extension field metadata as information.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)