Re: Spec changes for deletion vectors

Im +1 for adding DV (Goal 1) and also +1 for the ability for Iceberg readers to read Delta Lake DV’s, as the magic byte, CRC make sense design-wise (Goal 2). Its nice that there's cross-community collaboration probably in other areas Im not looking at, but I'm -0.5 on writing an otherwise unjust

Re: Spec changes for deletion vectors

I agree with everything Russell said. I think we should move forward with the current format of DVs to favor compatibility. I'll add that I think the collaboration aspect likely applies to other aspects as well outside of Deletion Vectors (e.g. the work that is happening on Variant type). Thanks

Re: Spec changes for deletion vectors

I've thought about this a lot and talked it over with a lot of folks. As I've noted before my main concerns are A. Setting a precedent that we are delegating design decisions to another project B. Setting unnecessary requirements that can only really be checked by integration tests with another sy

Re: [DISCUSS] Discrepancy Between Iceberg Spec and Java Implementation for Snapshot summary's 'operation' key

> No. They were introduced at the same time. Great! Since the `summary` field and the `operation` key were introduced together, we should enforce the rule that the `summary` field must always have an accompanying `operation` key. This has been addressed in PR 11354 [1]. > I am strongly against thi

Re: [VOTE] Endpoint for refreshing vended credentials

-0 (non-binding) If multiple credentials are vended for a table (which is allowed) the current API requires all credentials to be refreshed, when any of the previous credentials expires. I think this is suboptimal (but can probably be made to work in most practical cases). Cheers, Dmitri. On Mon

Re: [VOTE] Endpoint for refreshing vended credentials

+1 On Mon, Oct 21, 2024 at 3:07 AM Eduard Tudenhöfner wrote: > Hey everyone, > > I'd like to vote on #11281 , > which introduces a new endpoint and allows > retrieving/refreshing vended credentials for a given table. > > Please vote +1 if you general

Re: [DISCUSS] Apache Iceberg 1.7.0 Release Cutoff

Hi Russell, There is a data correctness issue ( https://github.com/apache/iceberg/issues/11221) that I have a fix for ( https://github.com/apache/iceberg/pull/11247). This is a serious issue, and I'd like to see the fix go into 1.7.0. Eduard has already approved the PR, but he asked if you or Amogh

Re: [DISCUSS] Apache Iceberg 1.7.0 Release Cutoff

That's still my current plan On Mon, Oct 21, 2024 at 10:52 AM Rodrigo Meneses wrote: > Hi, team. Are we still targeting to cut off on October 25th and release by > Oct 31the, for the 1.7.0 release? > Thanks > -Rodrigo > > > On Thu, Oct 3, 2024 at 9:03 PM Jean-Baptiste Onofré > wrote: > >> Hi Ru

Re: [DISCUSS] Apache Iceberg 1.7.0 Release Cutoff

Hi, team. Are we still targeting to cut off on October 25th and release by Oct 31the, for the 1.7.0 release? Thanks -Rodrigo On Thu, Oct 3, 2024 at 9:03 PM Jean-Baptiste Onofré wrote: > Hi Russ > > As discussed during the community sync, I agree with this plan. > > In the meantime (as you saw o

[VOTE] Endpoint for refreshing vended credentials

Hey everyone, I'd like to vote on #11281 , which introduces a new endpoint and allows retrieving/refreshing vended credentials for a given table. Please vote +1 if you generally agree with the path forward. Please vote in the next 72 hours [ ] +1, c