You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iceberg.apache.org by Alex Stephen via dev <de...@iceberg.apache.org> on 2026/04/29 17:37:02 UTC
Validations in REST Fixture
Hello,
The Iceberg Terraform provider
<http://github.com/apache/iceberg-terraform>uncovered
the fact that the REST Fixture does not validate any id values (schema-id,
field-id, last-partition-id, etc) for duplication. This is one of many
validations the Fixture can perform.
I've raised a PR <https://github.com/apache/iceberg/pull/16148> to fix
this, but it's kicked off a conversation about the level of validation that
the REST Fixture should have.
I propose that the REST Fixture should validate the inputs as much as
possible, especially since all of our implementations test against the
fixture. Adding validations to the fixture will ensure that we can catch
downstream errors in the implementations.
Please take a look at the PR and I'd appreciate any community opinions
regarding the desired functionality level for the REST Fixture.
Thanks,
Alex Stephen
Re: Validations in REST Fixture
Posted by Eduard Tudenhöfner <et...@apache.org>.
Hey Alex,
I took a look at the PR. Typically, validations happen as part of *update
requirements *(*UpdateRequirements *is the main class), which are executed
and checked before any *updates* are applied on the commit path in
*CatalogHandlers*.
I don't think the scenario described in the PR is reproducible in the Java
reference implementation when using Table / View APIs because we have code
in *TableMetadata* & *ViewMetadata* that assigns a new schema ID when
schemas differ.
It would be good to understand how exactly the Terraform provider created
those requirements & updates for the Table update request.
On Wed, Apr 29, 2026 at 7:38 PM Alex Stephen via dev <de...@iceberg.apache.org>
wrote:
> Hello,
>
> The Iceberg Terraform provider
> <http://github.com/apache/iceberg-terraform>uncovered the fact that the
> REST Fixture does not validate any id values (schema-id, field-id,
> last-partition-id, etc) for duplication. This is one of many validations
> the Fixture can perform.
>
> I've raised a PR <https://github.com/apache/iceberg/pull/16148> to fix
> this, but it's kicked off a conversation about the level of validation that
> the REST Fixture should have.
>
> I propose that the REST Fixture should validate the inputs as much as
> possible, especially since all of our implementations test against the
> fixture. Adding validations to the fixture will ensure that we can catch
> downstream errors in the implementations.
>
> Please take a look at the PR and I'd appreciate any community opinions
> regarding the desired functionality level for the REST Fixture.
>
> Thanks,
>
> Alex Stephen
>