apache/iceberg · error · UnsupportedOperationException

Not a binary column

Error message

Not a binary column

What it means

TripleIterator.nextBinary() is a default method that throws UnsupportedOperationException; only iterators for BINARY/FLBA (fixed byte array) columns override it. Receiving this message means the binary accessor was called on a column whose physical type is not binary — the value-reader type dispatch disagrees with the file's column type.

Source

Thrown at parquet/src/main/java/org/apache/iceberg/parquet/TripleIterator.java:120

   * @return the next value as an un-boxed double
   * @throws java.util.NoSuchElementException if there are no more elements
   * @throws UnsupportedOperationException if the underlying data values are not doubles
   */
  default double nextDouble() {
    throw new UnsupportedOperationException("Not a double column");
  }

  /**
   * Returns the next value as a Binary.
   *
   * <p>This method has the same behavior as {@link #next()} and will advance this iterator.
   *
   * @return the next value as a Binary
   * @throws java.util.NoSuchElementException if there are no more elements
   * @throws UnsupportedOperationException if the underlying data values are not binary
   */
  default Binary nextBinary() {
    throw new UnsupportedOperationException("Not a binary column");
  }

  /**
   * Returns null and advances the iterator.
   *
   * <p>This method has the same behavior as {@link #next()} and will advance this iterator.
   *
   * @return null
   * @throws java.util.NoSuchElementException if there are no more elements
   */
  <N> N nextNull();
}

View on GitHub (pinned to 86d9c8fc54)

Solutions

  1. Confirm the column's physical type is BINARY (or FLBA) in the Parquet footer before using nextBinary()
  2. Fix the reader dispatch so string/binary Iceberg types bind to the binary reader for BINARY physical columns
  3. Reconcile the projected Iceberg schema with the actual file schema — a string-typed projection over an int column is invalid
  4. Use the generic next() accessor in custom iterator code when the physical type is uncertain
  5. Rewrite mismatched data files with the correct physical types

Example fix

// before: binary accessor on a non-binary column
Binary b = iterator.nextBinary();

// after: guard on physical type
PrimitiveTypeName p = desc.getPrimitiveType().getPrimitiveTypeName();
if (p != PrimitiveTypeName.BINARY && p != PrimitiveTypeName.FIXED_LEN_BYTE_ARRAY) {
  throw new IllegalArgumentException("Column " + desc + " is not binary");
}
Binary b = iterator.nextBinary();
Defensive patterns

Strategy: type-guard

Validate before calling

PrimitiveTypeName p = desc.getPrimitiveType().getPrimitiveTypeName();
if (p != PrimitiveTypeName.BINARY && p != PrimitiveTypeName.FIXED_LEN_BYTE_ARRAY) {
  throw new IllegalArgumentException("Column " + desc + " is not binary");
}

Type guard

boolean isBinaryColumn(ColumnDescriptor desc) {
  PrimitiveTypeName p = desc.getPrimitiveType().getPrimitiveTypeName();
  return p == PrimitiveTypeName.BINARY || p == PrimitiveTypeName.FIXED_LEN_BYTE_ARRAY;
}

Try / catch

try { b = iterator.nextBinary(); } catch (UnsupportedOperationException e) { throw new IllegalStateException("Expected BINARY/FLBA column but got: " + desc.getPrimitiveType(), e); }

Prevention

When it happens

Trigger: Calling nextBinary() on a TripleIterator whose primitive type is not BINARY/FLBA — e.g. an Iceberg string/uuid column mapped to a numeric physical type, or custom code invoking nextBinary() on an INT32/INT64 column.

Common situations: String/UUID columns stored as integers by another writer; Iceberg schema/physical schema divergence (string vs int) after unenforced external rewrites; bespoke ParquetValueReaders dispatching on Iceberg types without checking physical Parquet types.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors


AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12). Data as JSON: /api/errors/465c170a8ab30ec0. Report an issue: GitHub.