Adopting the v2 spec and making support guarantees will mean that we can add table properties to create v2 tables. The reason why it is hard to upgrade to v2 is that we haven't adopted it or made compatibility guarantees, so we don't want people using it in production.
On Tue, Jul 27, 2021 at 11:53 PM OpenInx <open...@gmail.com> wrote: > > 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 >>> >> -- Ryan Blue Tabular
