> adopt the pending v2 spec changes as the supported v2 spec
I assume this vote wants to reach the consistency between the community
members that we won't introduce any breaking changes in v2 spec, not
discuss exposing v2 to SQL tables like the following, right ?
CREATE TABLE prod.db.sample (
id bigint COMMENT 'unique id',
data string)
USING iceberg
TBLPROPERTIES (
'format.version' = '2'
);
If so, then I will give a binding +1 from my side because I don't have
other particular changes that need to be introduced in the v2 now.
For exposing the v2 to end users, I think we could also try to merge the
PR and clarify v2 as an experiential feature, because I found many people
are trying to test and benchmark the v2 feature based on the practice from
https://github.com/apache/iceberg/pull/2410. Using the
meta.upgradeToFormatVersion(2) was quite unfriendly for users to test this
v2 feature now.
Thanks.
On Wed, Jul 28, 2021 at 1:09 PM Jack Ye <yezhao...@gmail.com> wrote:
> (non-binding) +1, this looks like a clean cut to me. We have been testing
> v2 internally for quite a while now, hopefully it can become the new
> default version soon to enable row level delete and update.
>
> -Jack Ye
>
>
> On Tue, Jul 27, 2021 at 9:59 AM Ryan Blue <b...@apache.org> wrote:
>
>> I’d like to propose that we adopt the pending v2 spec changes as the
>> supported v2 spec. The full list of changes is documented in the v2
>> summary section of the spec <https://iceberg.apache.org/spec/#version-2>.
>>
>> The major breaking change is the addition of delete files and metadata to
>> track delete files. In addition, there are a few other minor breaking
>> changes. For example, v2 drops the block_size_in_bytes field in
>> manifests that was previously required and also omits fields in table
>> metadata that are now tracked by lists; schema is no longer written in
>> favor of schemas. Other changes are forward compatible, mostly
>> tightening field requirements where possible (e.g., schemas and
>> current-schema-id are now required).
>>
>> Adopting the changes will signal that the community intends to support
>> the current set of changes and will guarantee forward-compatibility for v2
>> tables that implement the current v2 spec. Any new breaking changes would
>> go into v3.
>>
>> Please vote on adopting the v2 changes in the next 72 hours.
>>
>> [ ] +1 Adopt the changes as v2
>> [ ] +0
>> [ ] -1 Do not adopt the changes, because…
>> --
>> Ryan Blue
>>
>
