fix: encoding of Variant object header field-id and offset sizes (#421)

### What

`VariantEncodingHelper` wrote and read the Variant object value header
with
`field_id_size_minus_one` and `field_offset_size_minus_one` in each
other's bit positions.

Per `apache/parquet-format` `VariantEncoding.md`, the object
`value_header` — the 6 bits above
the 2 basic-type bits — is laid out as:

```
                  5   4  3     2 1     0
                +---+---+-------+-------+
value_header    | R |   |       |       |
                +---+---+-------+-------+
                      ^     ^       ^
                      |     |       +-- field_offset_size_minus_one
                      |     +-- field_id_size_minus_one
                      +-- is_large
```

`MakeObjectHeader` and `ParseObjectHeader` had the two 2-bit fields
transposed, and the layout
comment above them documented the same transposition — so the block was
internally consistent
rather than wrong in one expression.

`is_large` was already correct. The array header and metadata header
helpers were checked and
match the spec. This affects the object header only.

### Impact

Reader and writer shared the inverted convention, so arrow-dotnet
round-tripped its own output
correctly. The bug was only observable across implementations, and only
when
`fieldIdSize != offsetSize` — when the two are equal, transposing them
is a no-op.

Those sizes are computed independently in `VariantValueWriter`
(`fieldIdSize` from the maximum
field ID, `offsetSize` from the encoded data length), so they diverge
routinely: for example an
object drawn from a >255-entry metadata dictionary (2-byte field IDs)
whose own field data is
under 256 bytes (1-byte offsets).

For `fieldIdSize=2, offsetSize=1, isLarge=false`, the spec-correct
header byte is `0x12`;
before this change we emitted `0x06`, and read `0x12` back as
`fieldIdSize=1, offsetSize=2`.
Such objects were silently misparsed in both directions — field IDs and
offsets read at the
wrong widths, surfacing as garbage field values or out-of-range offsets
rather than a clean
error.

### Changes

- `VariantEncodingHelper.MakeObjectHeader` / `ParseObjectHeader`: swap
the two shifts, and
correct the layout comment. The `out` parameters were already named
correctly, so neither
call site — `VariantValueWriter` or `VariantObjectReader` — needed
changes.
- `VariantEncodingHelperTests`: add `MakeObjectHeaderUsesSpecBitLayout`
and

Closes #420.
4 files changed
tree: 2df86dd42cdb2735ec29972e41019f9b5c041e32
  1. .github/
  2. ci/
  3. dev/
  4. docs/
  5. examples/
  6. format/
  7. src/
  8. test/
  9. .asf.yaml
  10. .editorconfig
  11. .gitattributes
  12. .gitignore
  13. .gitmodules
  14. .pre-commit-config.yaml
  15. .shellcheckrc
  16. Apache.Arrow.sln
  17. Apache.Arrow.Tests.slnf
  18. ApacheArrow.snk
  19. CODE_OF_CONDUCT.md
  20. CONTRIBUTING.md
  21. Directory.Build.props
  22. Directory.Build.targets
  23. Directory.Packages.props
  24. LICENSE.txt
  25. logo_asf.png
  26. NOTICE.txt
  27. README.md
README.md

Apache Arrow .NET

An implementation of Arrow targeting .NET Standard.

See our current feature matrix for currently available features.

Implementation

  • Arrow specification 1.0.0. (Support for reading 0.11+.)
  • C# 11
  • .NET Standard 2.0 and .NET 6.0
  • Asynchronous I/O
  • Uses modern .NET runtime features such as Span<T>, Memory<T>, MemoryManager<T>, and System.Buffers primitives for memory allocation, memory storage, and fast serialization.
  • Uses Acyclic Visitor Pattern for array types and arrays to facilitate serialization, record batch traversal, and format growth.

Known Issues

  • Cannot read Arrow files containing tensors.
  • Cannot easily modify allocation strategy without implementing a custom memory pool. All allocations are currently 64-byte aligned and padded to 8-bytes.
  • Default memory allocation strategy uses an over-allocation strategy with pointer fixing, which results in significant memory overhead for small buffers. A buffer that requires a single byte for storage may be backed by an allocation of up to 64-bytes to satisfy alignment requirements.
  • There are currently few builder APIs available for specific array types. Arrays must be built manually with an arrow buffer builder abstraction.
  • FlatBuffer code generation is not included in the build process.
  • Serialization implementation does not perform exhaustive validation checks during deserialization in every scenario.
  • Throws exceptions with vague, inconsistent, or non-localized messages in many situations
  • Throws exceptions that are non-specific to the Arrow implementation in some circumstances where it probably should (eg. does not throw ArrowException exceptions)
  • Lack of code documentation
  • Lack of usage examples

Usage

using System.Diagnostics;
using System.IO;
using System.Threading.Tasks;
using Apache.Arrow;
using Apache.Arrow.Ipc;

public static async Task<RecordBatch> ReadArrowAsync(string filename)
{
    using (var stream = File.OpenRead(filename))
    using (var reader = new ArrowFileReader(stream))
    {
        var recordBatch = await reader.ReadNextRecordBatchAsync();
        Debug.WriteLine("Read record batch with {0} column(s)", recordBatch.ColumnCount);
        return recordBatch;
    }
}

Status

Memory Management

  • Allocations are 64-byte aligned and padded to 8-bytes.
  • Allocations are automatically garbage collected

Arrays

Primitive Types

  • Int8, Int16, Int32, Int64
  • UInt8, UInt16, UInt32, UInt64
  • Float, Double, Half-float (.NET 6+)
  • Binary (variable-length)
  • String (utf-8)
  • Null

Parametric Types

  • Timestamp
  • Date32
  • Date64
  • Decimal
  • Time32
  • Time64
  • Binary (fixed-length)
  • List
  • Struct
  • Union
  • Map
  • Duration
  • Interval

Type Metadata

  • Data Types
  • Fields
  • Schema

Serialization

  • File
  • Stream

IPC Format

Compression

  • Buffer compression and decompression is supported, but requires installing the Apache.Arrow.Compression package. When reading compressed data, you must pass an Apache.Arrow.Compression.CompressionCodecFactory instance to the ArrowFileReader or ArrowStreamReader constructor, and when writing compressed data a CompressionCodecFactory must be set in the IpcOptions. Alternatively, a custom implementation of ICompressionCodecFactory can be used.

Not Implemented

  • Serialization
    • Exhaustive validation
    • Run End Encoding
  • Types
    • Tensor
  • Arrays
    • Large Arrays. There are large array types provided to help with interoperability with other libraries, but these do not support buffers larger than 2 GiB and an exception will be raised if trying to import an array that is too large.
      • Large Binary
      • Large List
      • Large String
    • Views
      • Binary
      • List
      • String
      • Large Binary
      • Large List
      • Large String
  • Array Operations
    • Equality / Comparison
    • Casting
  • Compute
    • There is currently no API available for a compute / kernel abstraction.

Build

Install the latest .NET Core SDK from https://dotnet.microsoft.com/download.

dotnet build

NuGet Build

To build the NuGet package run the following command to build a debug flavor, preview package into the artifacts folder.

dotnet pack

When building the officially released version run: (see Note below about current git repository)

dotnet pack -c Release

Which will build the final/stable package.

NOTE: When building the officially released version, ensure that your git repository has the origin remote set to https://github.com/apache/arrow.git, which will ensure Source Link is set correctly. See https://github.com/dotnet/sourcelink/blob/main/docs/README.md for more information.

There are two output artifacts:

  1. Apache.Arrow.<version>.nupkg - this contains the executable assemblies
  2. Apache.Arrow.<version>.snupkg - this contains the debug symbols files

Both of these artifacts can then be uploaded to https://www.nuget.org/packages/manage/upload.

Docker Build

Build from the Apache Arrow project root.

docker build -f csharp/build/docker/Dockerfile .

Testing

dotnet test

All build artifacts are placed in the artifacts folder in the project root.

Coding Style

This project follows the coding style specified in Coding Style.

Updating FlatBuffers code

See https://flatbuffers.dev/languages/c_sharp/ for how to get the flatc executable.

Run flatc --csharp on each .fbs file in the format folder. And replace the checked in .cs files under FlatBuf with the generated files.

Update the non-generated FlatBuffers .cs files with the files from the google/flatbuffers repo.