What causes "Setting values is not supported" in apache/iceberg?

Do not mutate rows from static tasks; instead build a new record/copy when you need a modified value.

apache/iceberg · error · UnsupportedOperationException

Setting values is not supported

Error message

Setting values is not supported

What it means

StaticDataTask's internal StructLike implementation throws UnsupportedOperationException from set() because static data tasks expose immutable, read-only rows backed by a fixed values array. Iceberg models row mutation as unsupported here by design: static tables are read-only snapshots of data at a point in time. Any code path that attempts to write into a row from a static task is a programming error.

Source

Thrown at core/src/main/java/org/apache/iceberg/StaticDataTask.java:163

    private final Object[] values;

    private Row(Object... values) {
      this.values = values;
    }

    @Override
    public int size() {
      return values.length;
    }

    @Override
    public <T> T get(int pos, Class<T> javaClass) {
      return javaClass.cast(values[pos]);
    }

    @Override
    public <T> void set(int pos, T value) {
      throw new UnsupportedOperationException("Setting values is not supported");
    }
  }
}

View on GitHub (pinned to 86d9c8fc54)

Solutions

Do not mutate rows from static tasks; instead build a new record/copy when you need a modified value.
If your writer mutates a reused record, allocate a fresh mutable StructLike (e.g. your own GenericRecord or array-backed implementation) instead of reusing the task's record.
When buffering rows for rewriting, wrap the immutable record in your own mutable container and copy values via get().
If you need updatable data, scan the actual data table rather than a static/metadata table.

Example fix

// before
StructLike row = tasks.iterator().next();
row.set(0, newValue); // UnsupportedOperationException

// after
StructLike src = tasks.iterator().next();
StructLike copy = new InternalRecord(/* mutable impl */);
for (int i = 0; i < copy.size(); i++) { copy.set(i, src.get(i, Object.class)); }
copy.set(0, newValue);

Defensive patterns

Strategy: type-guard

Type guard

// Java
boolean isMutable(StructLike row) {
  return !(row instanceof StaticDataTask.Record);
}

Try / catch

// Java
try {
  row.set(pos, value);
} catch (UnsupportedOperationException e) {
  // clone into a mutable StructLike and retry
  StructLike copy = copyOf(row);
  copy.set(pos, value);
}

Prevention

Treat StructLike rows from metadata/static table scans as immutable.
Copy values into your own mutable record before rewriting rows.
Avoid writer code paths that mutate records in place when consuming static task output.

When it happens

Trigger: Calling StructLike.set(pos, value) on a record obtained from a StaticDataTask (e.g. rows yielded by metadata tables like table.metadataTable("entries") or static table scans), or passing such a StructLike into an API that mutates records in place (some writers/updaters do).

Common situations: Generic code that assumes every StructLike is mutable (e.g. reuse-a-record write patterns) being fed rows from metadata-table scans; copying logic that mutates the destination record; unit tests reusing records across static task iterations.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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