Re: [DISCUSS] Proposal: Returning Commit Results from commit()

napshot in by searching the commits for this UUID. >>> >>> >>> >>> yuxia ezt írta (időpont: 2025. szept. >>> 12., P, 14:30): >>> >>> Hi, Jason. >>> >>> >>> >>> Thanks for bringing this up. When i

Re: [DISCUSS] Donation of Dremio Auth Manager to the Apache Iceberg project

I'm also really strongly in favor of getting these capabilities into the project as well! I think mainly I'm also waiting to see the design for how we will replace what is currently in the codebase and how it will have new functionality introduced. I want to avoid us taking in an independent projec

Re: [DISCUSS] Support SQL:2011 compliant DECIMAL type evolution with scale changes

This has already been proposed as part of v4, see Edwards column metrics expansion proposal On Thu, Sep 11, 2025 at 4:54 AM rice Zhang wrote: > Hi, Junwang > > We're discussing the storage of lower and upper bounds for decimal values > in manifest files and their compatibility after type evoluti

Re: [DISCUSS] Proposal: Returning Commit Results from commit()

I don't think I'm opposed to this idea in general but I think we probably need to get some concrete examples of how this is going to be used by a consumer. Since this would require modifying every implementation of XXXOperation that we currently have; it's a rather heavy change and should probably

Re: [DISCUSS] FileFormat API proposal

hich then has to support both InternalRow and >> PositionDelete. >> >> In both cases, the FormatModelRegistry API will still expose the more >> concrete types (PositionDelete / InternalRow). However, under the *first >> approach*, the lower-level API only needs to handle

Re: [DISCUSS] Removal of Individually Curated Blogs and Talks and Position on Vendor Documentation

you on Slack. > > > On Fri, Sep 19, 2025 at 2:39 PM Russell Spitzer > wrote: > >> Does anyone know if we can support an orphaned page in MkDocs without the >> new Markdown linter complaining? I'm testing >> out a build where we keep the page but disabl

Re: [DISCUSS] Removal of Individually Curated Blogs and Talks and Position on Vendor Documentation

maintain the list in its >>>> current form. I believe the original intent was to include references to >>>> any mentions of Iceberg to boost visibility as there was no company that >>>> would sponsor any media coverage for Iceberg in early days. At that time >>>>

Re: [DISCUSS] Removal of Individually Curated Blogs and Talks and Position on Vendor Documentation

about the projects. > So, just a blog page with links to different blog posts is good enough > (but it needs some attention to be "maintained"). > > Just my $0.01 > > Regards > JB > > On Thu, Sep 18, 2025 at 11:03 PM Russell Spitzer > wrote: > > >

[DISCUSS] Removal of Individually Curated Blogs and Talks and Position on Vendor Documentation

Hi Y'all We talked about this a bit in a community sync a while back and I know a bunch of committers have been working off some of the consensus we reached then but I'm not sure we ever actually documented this. *1. Should the Apache Iceberg community still maintain a set of Blogs and Talks that

Re: [Discuss] Deprecating Spark 3.4

+1. But I'm always on the aggressive side of dropping old releases. On Wed, Sep 17, 2025 at 4:31 PM Alex Stephen wrote: > +1 to deprecating it. > > Keeping support for Spark 3.4 in Iceberg will encourage users not to > upgrade to a more modern version. > > On Wed, Sep 17, 2025 at 1:33 PM Kevin L

Re: [VOTE] Spec: bring back added-rows in the snapshot fields

+1 (bind) On Mon, Sep 15, 2025 at 1:25 PM Steve wrote: > +1 (non-binding) > > On Mon, Sep 15, 2025 at 3:08 AM Péter Váry > wrote: > > > > +1 binding > > > > Prashant Singh ezt írta (időpont: 2025. > szept. 15., H, 11:59): > >> > >> +1 (non-binding) > >> > >> Best, > >> Prashant > >> > >> On Mo

Re: [DISCUSS] Iceberg REST Catalog Idempotency

I think based on the feedback on the proposal and in recent syncs we should probably move forward with the actual Spec Change PR so we can see what this looks like and move on to a discussion of how the Catalog test framework should test this. On 2025/08/22 18:26:23 huaxin gao wrote: > Hi all,

Re: [DISCUSS] V1 Manifests without row counts break V3 Tables

equiring > a repair operation is better than updating and then failing to write. > > On Fri, Sep 12, 2025 at 11:24 AM Russell Spitzer < > russell.spit...@gmail.com> wrote: > >> I'm in support of just converting the NPE for now into a clearer message >> and fina

Re: [DISCUSS] V1 Manifests without row counts break V3 Tables

I'm in support of just converting the NPE for now into a clearer message and finally finishing RepairMetadata/Manifests or whatever we have so folks can get those stats back into their manifests. On Fri, Sep 12, 2025 at 1:04 PM Christian Thiel wrote: > Dear all, > while implementing v3 support i

Re: [DISCUSS] FileFormat API proposal

onsibility to the engine-specific code, >where we already have some logic (e.g., pathTransformFunc) needed by >each engine to create the PositionDeleteAppender? > > Thanks, > Peter > > > Russell Spitzer ezt írta (időpont: 2025. > szept. 11., Cs, 0:11): > >> I&#

Re: [DISCUSS] Spec: bring back added-rows in the snapshot fields

+1, I also am fine with the name. On Wed, Sep 10, 2025 at 10:30 PM Steven Wu wrote: > > In the 1.10.0 RC5 voting thread > , > Christian brought up an inconsistency issue between the spec and the Java > implementation. Spec removed

Re: [DISCUSS] Support SQL:2011 compliant DECIMAL type evolution with scale changes

imal type evolves. >> >> Would love to hear your thoughts on how we should proceed with addressing >> this specific issue. >> >> Minglei >> >> rice Zhang 于2025年9月11日周四 19:47写道： >> >>> I couldn't find it in my search - would

Re: [DISCUSS] FileFormat API proposal

I'm a little confused here, I think Ryan mentioned this in the comment here https://github.com/apache/iceberg/pull/12774/files#r2254967177 >From my understanding there are two options? 1) We either are producing FormatModels that take a generic row type D and produce writers that all take D and w

Re: [VOTE] Deprecation of Position Deletes with Row Data

+1 On Wed, Sep 10, 2025 at 10:58 AM Péter Váry wrote: > The Position Deletes With Row (PDWR) feature, originally introduced in the > Iceberg V2 specification, has been deprecated in V3. > > Following the discussion in the previous thread [1], we propose > deprecating PDWR in the Java implementat

Re: [VOTE] Release Apache Iceberg 1.10.0 RC5

d. >> If anyone is aware of a tool creating v3 tables already without this >> field, please let us know here. Iceberg Java does write the "added-rows" >> field to this date, even though its temporarily missing from the spec ;) >> Tables created with the java sdk, ar

Re: [VOTE] Release Apache Iceberg 1.10.0 RC5

I think ... we would just add added-rows back into the snapshot to fix this then? Otherwise we would have to require catalogs to compute added rows by reading the manifestList. I think we forgot there could be a snapshot that would be added to the base metadata via a REST serialization and not di

Re: [VOTE] Release Apache Iceberg 1.10.0 RC5

+1 (Binding) Verified sigs/checksums Verified Rat Ran full Build and test Bothered Aihua to run the internal SF suite :) On Mon, Sep 8, 2025 at 4:33 PM Drew wrote: > +1 (non binding) > >- verified signature and checksums >- verified RAT license check >- verified build/te

Re: [DISCUSS] Enable merge queue in iceberg repositories

+1, I think it's definitely worth trying out, and if we do have issues it's easy to just turn it off again. On Fri, Aug 29, 2025 at 3:35 AM Renjie Liu wrote: > Thanks everyone for joining the discussion. > > There is no objection or concerns about this, I'll fire a jira ticket to > enable it. >

Re: Increasing the max table format version to 3 in REST Spec

do it! +1 On Thu, Aug 28, 2025 at 11:22 AM Kevin Liu wrote: > +1 and +1 on the PR. Exciting! > > Best, > Kevin Liu > > On Thu, Aug 28, 2025 at 9:18 AM Ryan Blue wrote: > >> +1. Thanks for fixing this, JB! >> >> On Wed, Aug 27, 2025 at 8:05 PM Amogh Jahagirdar <2am...@gmail.com> >> wrote: >> >>>

Re: [DISCUSS] Add GitHub action to lint markdown files

Great Idea, support all the things Eduard and Fokko said as well. Probably makes sense to keep using tools we already have if possible On Thu, Aug 21, 2025 at 11:13 AM Fokko Driesprong wrote: > Hey Manu, > > Thanks for suggesting this, and I strongly support using a linter. > Recently I noticed

Re: [DISCUSS] Deprecation of Position Deletes with Row Data

in >> implementation notes. Some libraries such as iceberg-rust are currently >> working on v2 support, and if we have that statement in spec we could >> ignore the support of row data in position deletes. >> >> On Wed, Aug 20, 2025 at 12:53 AM Russell Spitzer < &

Re: [DISCUSS] V4 - Parquet as Metadata File Format

; I'm interested in working on this change as well. I think it pairs >>> nicely with the proposal for per column structs for statistics. >>> > >>> > Thanks, >>> > Harman >>> > >>> > On Thu, Jun 12, 2025 at 9:43 PM Russell Sp

Re: [DISCUSS] Deprecation of Position Deletes with Row Data

planning phase. Curious if > there is any library that actually uses this. > > I do agree with Russell, and maybe deprecating this at the spec > level makes more sense. > > Kind regards, > Fokko > > Op di 19 aug 2025 om 17:54 schreef Russell Spitzer < > russell.spi

Re: [DISCUSS] Deprecation of Position Deletes with Row Data

I'm not sure we can deprecate the column in a library version update, but currently it is marked as optional and I don't think the Apache Java Library even has a way of writing or reading them. On Tue, Aug 19, 2025 at 10:15 AM Péter Váry wrote: > During the last community sync (30/07), we discus

Re: [VOTE] mark 503 as non-retryable error code for the Update Table

+1 On Tue, Aug 19, 2025 at 10:28 AM Eduard Tudenhöfner < etudenhoef...@apache.org> wrote: > +1 > > On Tue, Aug 19, 2025 at 5:23 PM Ryan Blue wrote: > >> +1 >> >> On Mon, Aug 18, 2025 at 4:50 PM huaxin gao >> wrote: >> >>> +1 (non-binding) >>> >>> On Mon, Aug 18, 2025 at 4:33 PM Hussein Awala w

Re: [QUESTION] What type promotion actually means

+1 to what Micah said :) sorry about the typo On Mon, Aug 18, 2025 at 9:45 AM Russell Spitzer wrote: > +1 to what Micaah , We have never really written rules about what is > "allowed" in this particular context but since > a reader needs to be able to handle both int/long va

Re: [QUESTION] What type promotion actually means

+1 to what Micaah , We have never really written rules about what is "allowed" in this particular context but since a reader needs to be able to handle both int/long values for the column, there isn't really any danger in writing new files with the narrower type. If a reader couldn't handle this, t

Re: [EXTERNAL] Re: [DISCUSS] Iceberg Summit NA 2026 and Iceberg Summit EU 2026 ?

I would love to have an event that's easier for non-us'ian members of the community to get to! I wouldn't mind just alternating NA and EU (and Asia?) but if we can find enough sponsorship and content I wouldn't mind multiple events. On Mon, Jul 28, 2025 at 1:57 PM Kevin Liu wrote: > +1 for both

Re: [VOTE] Update the table statistics (puffin stats) spec

I'm generally a +1 here since any implementation not using a long would have hit a bug a long time ago when interacting with any of the major engines I do want to make sure we let this vote go for at least a few more days to tease out any users with strong opinions. Unless we see a major implemen

Re: [DISCUSS] v4 - Improved column statistics

storing the expressions stats according to the > structure proposed here. But I wouldn't over-complicate the current > proposal by adding this just yet. We can talk about extending stats to > expressions in another proposal once we have the structure and ID > assignment done. > >

Re: [DISCUSS] v4 - One file commits

gt; proposal that @Russell Spitzer shared are > pretty aligned. I was just chatting with Russell about this, and we think > it'd be best to combine both proposals and have a singular large effort on > this. I can also set up a focused community discussion (similar to what >

[ANNOUNCE] Welcome Prashant Singh as a new Apache Iceberg Committer

Hey y'all, I'm glad to announce for the Iceberg PMC that Prashant Singh is now a committer on the Apache Iceberg project. Thanks for all your hard work and I know we are all glad to see what else you will be contributing to the project in the future. On behalf of the Iceberg PMC, Russ

Re: [DISCUSS] v4 - Improved column statistics

I'm also sorry I missed the discussion because I was busy trying to keep a nearly-3 year old occupied on a plane :) I think the proposal is pretty strong although I have one request. Currently, we have the ability to note the sort order which was applied to a data file but we have know way of know

Re: [DISCUSS] Iceberg REST FGAC proposal

I think this is a really interesting approach as we've talked about in a few community syncs as well as in some other chats. If I understand the proposal correctly, we are essentially formalizing a way to return the FGAC "protection expressions" from the catalog to a trusted engine for executio

Re: [DISCUSS] v4 - One file commits

Hey y'all! We (Yi Fang, Steven Wu and Myself) wanted to share some of the thoughts we had on how one-file commits could work in Iceberg. This is pretty much just a high level overview of the concepts we think we need and how Iceberg would behave. We haven't gone very far into the actual implementa

Re: Iceberg Interval Types Proposal

t;>> >>>> How does everyone feel about moving forward with the support of >>>> Year-Month and Day-Time Intervals, especially for the part about having >>>> 16-byte signed values to represent nanoseconds. >>>> >>>> The change will f

Re: [VOTE] Release Apache Iceberg 1.9.2 RC0

+1 Checked licenses, RAT, Build, Smoke Tested with Spark. On Mon, Jul 7, 2025 at 6:05 PM Prashant Singh wrote: > Hi everyone, > > I propose the following RC to be released as the official Apache Iceberg > 1.9.2 release. > > The commit id is 071d5606bc6199a0be9b3f274ec7fbf111d88821 > * This corr

Re: [Discuss] Proposal to support set(metadata) on TableOperations

I think that was my request before as well :) I want a Catalog api for "register" directly then each implementation can decide how that gets applied. On Wed, Jul 9, 2025 at 4:13 PM Ryan Blue wrote: > Thanks for bringing this up, Hongyue. I think the logic here makes sense > and that `commit(base

Re: [DISCUSS] Replace table transaction in REST Catalog

I left some comments on https://github.com/apache/iceberg/issues/12738#issuecomment-3009087235 but I think this is probably a good time to revisit whether we want to keep the "truncate + maintain state" behavior or switch to "drop + create". I think this will probably require a breaking change in t

Re: Iceberg 0.10.0 release update - June 18, 2025

I probably wouldn't block on those issues being fixed but if we are really worried we should just disable that functionality. On Wed, Jun 25, 2025 at 12:27 PM Steven Wu wrote: > Amogh, thanks for sharing the input. Conceptually, I agree that it is good > to fix those issues in the 1.10.0 release

Re: [DISCUSS] Enabling more Meetups

on this thread, and that’s why I >> shared the trademark policy. >> >> The updated proposal (including Max and Danica updates) looks good to me. >> >> Regards >> JB >> >> Le jeu. 29 mai 2025 à 14:48, Rich Bowen a écrit : >> >>> >>&g

Re: [DISCUSS] Proposal for Iceberg 1.9.2 Release to Fix Critical REST Client Issue

Sorry I didn't get to reply here, I think the fix Ajantha is contributing is extremely important but probably out of scope for a patch release. Because it will take a bit of manual intervention to fix after jumping to the next version I think we should save this for 1.10.0 which also should come ou

Re: [DISCUSS] V4 - Parquet as Metadata File Format

t; Let me know the results of your POC and happy to collaborate on this work. > > > - Ajantha > > On Fri, Jun 13, 2025 at 3:16 AM Russell Spitzer > wrote: > >> All we have to do is add the parquet module as a test dependency, working >> on a poc now. I don't t

Re: [DISCUSS] V4 - Parquet as Metadata File Format

se metadata structure can change? > > - Ajantha > > On Thu, May 29, 2025 at 11:37 PM Russell Spitzer < > russell.spit...@gmail.com> wrote: > >> Hi Y'all >> >> As discussed in the last community sync, we are beginning to gather up >> folks who are int

Re: [DISCUSS] June board report

Looking good! On Wed, Jun 4, 2025 at 4:21 PM Ryan Blue wrote: > Hi everyone, > > Here’s my draft of our board report for June. I went through the old syncs > for highlights, but please reply if you want me to add any more! > > Ryan > Description: > > Apache Iceberg is a table format for huge ana

Re: [DISCUSS] v4 - One file commits

I’m also super excited about this idea On Thu, May 29, 2025 at 3:37 PM Amogh Jahagirdar <2am...@gmail.com> wrote: > Thanks for kicking this thread off Ryan, I'm interested in helping out > here! I've been working on a proposal in this area and it would be great to > collaborate with different fol

[DISCUSS] API: Rename RowDelta deleteFile to removeRows

Ryan pointed out to me that whenI added the "deleteFile" method I was not following the convention already being used within the RowDelta operation and instead had copied the OverwriteFiles API. To fix this I think it would be great to change the API to "removeRows" to match the other APIs in the c

Re: [Discuss] Make identity(String sourceName, String targetName) Public

gt; public scope > * identity transform builder is the only one where targetName builder is > not public > * handle the partition column rename use case > > So it seems reasonable to me. > > > On Wed, May 21, 2025 at 2:49 PM Russell Spitzer > wrote: > >> Hi Y

[DISCUSS] V4 - Parquet as Metadata File Format

Hi Y'all As discussed in the last community sync, we are beginning to gather up folks who are interested in various efforts for Iceberg V4. To that end, I'd like to use this thread as a gathering point for folks interested in the metadata file format shift to Parquet. I wrote a quick abstract to d

Re: [DISCUSS] Enabling more Meetups

: > > > On 2025/05/23 19:24:28 Russell Spitzer wrote: > > Hey Y'all > > > > Basically I would like to get the PMC out of the meetup approval > business > ... > > Please let me know what you think, > > (Board hat) > > A critical role of a P

[ANNOUNCE] Apache Iceberg release 1.9.1

I'm pleased to announce the release of Apache Iceberg 1.9.1! Apache Iceberg is an open table format for huge analytic datasets. Iceberg delivers high query performance for tables with tens of petabytes of data, along with atomic commits, concurrent writes, and SQL-compatible table evolution. This

Re: [DISCUSS] Enabling more Meetups

t; Le mar. 27 mai 2025 à 17:52, Ryan Blue a écrit : >> >> >> >> JB, can you give us a bit more context about why you're recommending >> those pages? Do they have policies that already do what is being suggested? >> Do they impose limits that mean we could not

Re: [RESULT][VOTE] Release Apache Iceberg 1.9.1 RC1

I forgot Peter! I'm so sorry! That should have been +1: 4 (binding), 5 (non-binding). {Russell, Steven Wu, Fokko, Peter} | {JB, Karuppayya, Kevin, Huaxin, Aihua} +0: 0 (binding), 0 (non-binding) -1: 0 (binding), 0 (non-binding) On Tue, May 27, 2025 at 4:29 PM Russell Spitzer

[RESULT][VOTE] Release Apache Iceberg 1.9.1 RC1

>> >> On Tue, May 27, 2025 at 9:06 AM Russell Spitzer < >> russell.spit...@gmail.com> wrote: >> >>> For all those who haven't seen this before, GPG key signing is a very >>> "early hacker" sort of thing. The idea is the only way to

Re: [VOTE] Release Apache Iceberg 1.9.1 RC1

ignature, checksum, license and ran some tests. >> >> On Tue, May 27, 2025 at 9:06 AM Russell Spitzer < >> russell.spit...@gmail.com> wrote: >> >>> For all those who haven't seen this before, GPG key signing is a very >>> "early hacker" so

Re: [DISCUSS] Apache Iceberg 1.10.0 release

Thanks Steven! I know we are going to have a busy June but I think pretty much everything (except Geo Types) is close to being ready in the reference Spark implementation. On Tue, May 27, 2025 at 1:08 PM Steven Wu wrote: > > As discussed in the community sync, we are planning for the next 1.10.0

Re: Wide tables in V4

than > writing to a separate file, I am not sure how much worse it is though. > > On Tue, May 27, 2025 at 9:40 AM Russell Spitzer > wrote: > >> I think that "after the fact" modification is one of the requirements >> here, IE: Updating a single column without

Re: Wide tables in V4

at tooling actually supports this though. Could be >> interesting to see what the history of this is. >> https://lists.apache.org/thread/rcv1cxndp113shjybfcldh6nq1t3lcq3, >> https://lists.apache.org/thread/k5nv310yp315fttcz213l8o0vmnd7vyw >> >> On Tue, May 27, 2025 at 8

Re: [VOTE] Release Apache Iceberg 1.9.1 RC1

in 'apache-iceberg-1.9.1.tar.gz' >> gpg: Signature made Wed May 21 15:19:17 2025 PDT >> gpg:using RSA key xxx >> gpg: Good signature from "Russell Spitzer (CODE SIGNING KEY) >> " [unknown] >> gpg: WARNING: This key is not certified

Re: Wide tables in V4

I have to agree that while there can be some fixes in Parquet, we fundamentally need a way to split a "row group" or something like that between separate files. If that's something we can do in the parquet project that would be great but it feels like we need to start exploring more drastic options

[DISCUSS] Enabling more Meetups

Hey Y'all I know there has been a lot of confusion over who is allowed to host a meetup and what it can be called. Technically, I believe the PMC is supposed to be involved in anything involving the Apache Iceberg trademark but I'd like to pre-approve a bunch of meetups if we have consensus. Basi

Re: [VOTE] Release Apache Iceberg 1.9.1 RC1

;> anymore) >>> https://github.com/apache/iceberg/issues/13122 >>> >>> If it is induced by 1.9.0, we should probably fix it and include it in >>> RC? >>> No functional impact. >>> >>> - Ajantha >>> >>> On Thu, May

[DISCUSS] Overview of the Table Specification Lifecycle and how to Make Changes

Hi Y'all, As the community grows I wanted to get some of our tribal knowledge written down and get some consensus on what I think isn't really written down anywhere. Please take a look at let me know if you have any questions or comments. I'm imagining this would go either parallel to Contributing

Re: [VOTE] Release Apache Iceberg 1.9.1 RC0

de in the > following release. I feel it's a regression which didn't catch in 1.9.0 and > make sense to fix in 1.9.1. > > Thanks Russell. Busy with oncall to miss today's sync. I guess we agree to > move forward to make this fix? > > > > On Wed, May 21, 202

[VOTE] Release Apache Iceberg 1.9.1 RC1

Hi Y'all, I propose that we release the following RC as the official Apache Iceberg 1.9.1 release. The commit ID is f40208ae6fb2f33e578c2637d3dea1db18739f31 * This corresponds to the tag: apache-iceberg-1.9.1-rc1 * https://github.com/apache/iceberg/commits/apache-iceberg-1.9.1-rc1 * https://githu

Re: [VOTE] Release Apache Iceberg 1.9.1 RC0

probably need > to work on a better/complete fix. > > I'm not sure reverting this change would make sense either. I'm more > in favor of continuing the 1.9.1 vote. > > Regards > JB > > On Mon, May 19, 2025 at 6:25 PM Russell Spitzer > wrote: > > > &

[Discuss] Make identity(String sourceName, String targetName) Public

Hi Y'all We've been considering making a change to the Identity Partition Transform builder. Unlikely all of the other builders, Identity doesn't allow you to make an Identity Transform with a name different from the column you are transforming. We want to be able to construct in memory a TableMe

Re: [VOTE] Adopt the v3 spec changes

+1 (binding) On Tue, May 20, 2025 at 11:02 AM Steven Wu wrote: > +1 (binding) > > On Tue, May 20, 2025 at 5:25 AM Manu Zhang > wrote: > >> +1 (non-binding). Thanks Ryan for driving this and everyone contributing >> to the new features. >> >> Regards, >> Manu >> >> Péter Váry 于2025年5月20日 周二20:14

Re: [VOTE] Release Apache Iceberg 1.9.1 RC0

t; >>>>> It runs tests against several catalogs, including HMS, Glue, >>>>> JDBC (PostgreSQL), REST (Polaris, Unity, S3 Tables, Tabular), Nessie, and >>>>> Snowflake. >>>>> >>>>> >>>>> >>>>> BR, >>>>> >>&g

Re: [VOTE] Release Apache Iceberg 1.9.1 RC0

+1 (Binding) All the normal things and also checked manually ---> scala> import org.apache.iceberg.IcebergBuild import org.apache.iceberg.IcebergBuild scala> IcebergBuild.version res0: String = 1.9.1 On Fri, May 16, 2025 at 4:32 PM Russell Spitzer wrote: > Hi Y'all, >

[VOTE] Release Apache Iceberg 1.9.1 RC0

Hi Y'all, I propose that we release the following RC as the official Apache Iceberg 1.9.1 release. The commit ID is 5541cf84b9e139d8dd22db44db7f592c3a2d * This corresponds to the tag: apache-iceberg-1.9.1-rc0 * https://github.com/apache/iceberg/commits/apache-iceberg-1.9.1-rc0 * https://githu

Re: [Discuss] Iceberg 1.9.1 Release

Steven explained the Flink issue to me, Flink 2.0 isn't in 1.9.0 so not an issue. On Fri, May 16, 2025 at 12:20 PM Russell Spitzer wrote: > Ok so far of the lists proposed above I only picked 2 fixes that apply > cleanly and (we double checked) > actually apply to 1.9.0. Som

Re: [Discuss] Iceberg 1.9.1 Release

On Tue, May 13, 2025, 06:42 Jean-Baptiste Onofré wrote: >> >>> Hi >>> >>> I did a fix/improvement on Avro. I will propose to do new Avro releases. >>> Maybe worth to include in Iceberg 1.9.1 if the timing is ok. >>> >>> Regards

Re: Spark 4.0/Iceberg Integration Merged – Spark 3.5 Merges Can Resume

Thanks for getting this in! On Wed, May 14, 2025 at 5:39 PM huaxin gao wrote: > Dear all, > > Thank you so much for your patience and support! > > The Spark 4.0/Iceberg integration PR has now been merged. You can go ahead > and resume normal merging on Spark 3.5. > > Really appreciate everyone’s

Re: [VOTE] Clarify writer requirements in the spec to prevent orphan DVs

+1 (Binding) On Wed, May 14, 2025 at 10:52 AM Anton Okolnychyi wrote: > Hi all, > > I propose the following update to the spec to clarify that writers must > remove any deletion vector that applies to a data file when that data file > is removed from the metadata, as previously brought up by Ste

Re: [Discuss] Iceberg 1.9.1 Release

t; >> * Core: Disallow creation of invalid PartitionSpec #12887 >> <https://github.com/apache/iceberg/pull/12887> >> * GCP: Support multiple storage credential prefixes #12881 >> <https://github.com/apache/iceberg/pull/12881> >> * Build, Core

Re: [Discuss] Iceberg 1.9.1 Release

e Onofré wrote: > Hi Russ > > Yes, agree. Your PR is good and already merged. > > I don't have anything blocker for 1.9.1 (still working on source-ids, > but definitely not for 1.9.1). > > Thanks ! > Regards > JB > > On Fri, May 2, 2025 at 11:47 PM Russel

Re: [DISCUSS] [REST SPEC] Add first-row-id in the data files for Row Lineage

Makes sense to me, perhaps we should also add in a test that checks that the Datafile api object and the REst spec are always in sync? On Mon, May 12, 2025 at 10:52 AM Amogh Jahagirdar <2am...@gmail.com> wrote: > Thanks Prashant, I definitely agree the first_row_id will need to be added > to the

Re: [VOTE] Merge details about GZip metadata files to the spec.

+1 (binding) On Mon, May 12, 2025 at 5:32 AM Eduard Tudenhöfner wrote: > +1 (binding) > > On Mon, May 12, 2025 at 3:45 AM Gang Wu wrote: > >> +1 (non-binding) >> >> On Mon, May 12, 2025 at 3:27 AM Kevin Liu wrote: >> >>> +1 (non-binding) >>> >>> Thanks for starting a vote. >>> >>> There's extr

Re: [VOTE] Add encryption key updates to REST spec

+1 (binding) On Thu, May 8, 2025 at 10:37 AM Amogh Jahagirdar <2am...@gmail.com> wrote: > +1 (binding) > > On Thu, May 8, 2025 at 9:29 AM Eduard Tudenhöfner < > etudenhoef...@apache.org> wrote: > >> +1 (binding) >> >> On Thu, May 8, 2025 at 5:23 PM Ryan Blue wrote: >> >>> Hi everyone, >>> >>> I’

Re: [VOTE] Minor clarification for Geo Spec

+1 (bind) On Wed, May 7, 2025 at 7:32 AM Eduard Tudenhöfner wrote: > +1 (binding) > > On Wed, May 7, 2025 at 4:14 AM Gang Wu wrote: > >> The clarification is simple and clear from the writer's perspective. >> >> CMIW, the implication is that reader should drop bbox with any NaN value >> regardl

[Discuss] Iceberg 1.9.1 Release

Hey y'all! Thanks to @suilis we have learned that IcebergBuild.version() is returning unspecified for Iceberg 1.9.0. I have a PR up to fix this and I think this is a clear reason to do a 1.9.1 as soon a

Re: [DISCUSS] Finalizing the v3 spec

Sounds good to me, I think we can move ahead with this, for all intents and purposes I think we are past any breaking changes for Spec V3 and should consider it "stable" for implementation purposes. I want to work on some official descriptions of our spec versioning / library process to better expl

Re: [VOTE] Add encryption keys to table metadata

+1 On Wed, Apr 30, 2025 at 11:36 AM Szehon Ho wrote: > +1 > > Thanks > Szehon > > On Wed, Apr 30, 2025 at 4:10 AM Eduard Tudenhöfner < > etudenhoef...@apache.org> wrote: > >> +1 (binding) >> >> On Tue, Apr 29, 2025 at 9:29 PM Ryan Blue wrote: >> >>> Hi everyone, >>> >>> I’d like to propose merg

Re: [DISCUSS] Finalizing the v3 spec

We should probably come to a resolution on the compressed metadata.json name as well, although that's mostly retroactive. V3 would be the place where we could officially change the naming convention. I'm also interested in getting a release with the full implementation of V3 as it currently stands

Re: [VOTE] Release Apache Iceberg 1.9.0 RC2

+1 Binding Did the normal tests Rat Check and such Signature Checks out - Eduard's -- I do keep having an issue with some of the S3 Signing tests which require me to keep adjusting my local config inorder for the tests to past. (Requested ports already bound) So that would be nice to clean up if p

Re: [VOTE] Small spec change for default values

+1 (Binding) On Mon, Apr 21, 2025 at 4:21 PM Ryan Blue wrote: > Hi everyone, > > I’d like to vote on the spec changes in PR 12841 > . This is a small change > that makes handling default values for structs much easier. Initially, we > allowed both a

Re: Iceberg Interval Types Proposal

I think this is a pretty good idea for us to adopt in terms of compatibility with other systems and I really appreciate that Naren made sure to use a broad enough definition to support all available engines. I'm really interested to know how other folks feel about this proposal and I hope we can re

Re: [VOTE] Spec Update: Variant Field Lower/Upper Bounds

+1 (binding) On Fri, Apr 18, 2025 at 12:45 PM Ron Ortloff wrote: > +1 (non-binding) > > On Fri, Apr 18, 2025 at 9:47 AM Ryan Blue wrote: > >> +1 (binding) >> >> On Thu, Apr 17, 2025 at 8:27 PM Aihua Xu wrote: >> >>> Hi all, >>> >>> I'd like to initiate a vote to include a spec update for suppo

Re: [VOTE] Update row lineage spec ID assignment

+1 On Thu, Apr 17, 2025 at 12:30 PM Ryan Blue wrote: > Adding my own +1. > > On Thu, Apr 17, 2025 at 10:19 AM Daniel Weeks wrote: > >> +1 (binding) >> >> I think this update really helps ensure row ids will be present and >> reliable for upgraded tables. Thanks Ryan! >> >> On Wed, Apr 16, 2025

Re: [VOTE] Simplify multi-argument field-id(s) encoding

+1 (Bind) On Thu, Apr 17, 2025 at 8:14 AM Jean-Baptiste Onofré wrote: > +1 (non binding) (as said in the PR :)) > > Thanks ! > > Regards > JB > > On Thu, Apr 17, 2025 at 3:00 PM Fokko Driesprong wrote: > > > > Hi everyone, > > > > A while ago, I sent out a DISCUSS around simplifying the encodin

Re: [DISCUSS] Introducing Iceberg Features ?

I'm not a big fan of this, I am currently a strong supporter of the V3 is V3 approach. This is one of the reasons we decided to make row-lineage mandatory, we want to avoid encouraging engines from selectively adopting requirements. On Tue, Apr 15, 2025 at 1:42 PM Fokko Driesprong wrote: > Hey J

Re: [VOTE] Release Apache Iceberg 1.9.0 RC0

> JB > > On Tue, Apr 15, 2025 at 6:39 PM Russell Spitzer > wrote: > > > > We had a ticket about improving kafka connect distribution, > https://github.com/apache/iceberg/issues/12507 because the current docs > require you to build your own kafka-connect zip

Re: [VOTE] Release Apache Iceberg 1.9.0 RC0

We had a ticket about improving kafka connect distribution, https://github.com/apache/iceberg/issues/12507 because the current docs require you to build your own kafka-connect zip. On Mon, Apr 14, 2025 at 8:15 AM Jean-Baptiste Onofré wrote: > Another point that I saw: the kafka-connect runtime d

Re: [VOTE] Row lineage required for v3

+1 On Mon, Mar 31, 2025 at 2:22 PM Amogh Jahagirdar <2am...@gmail.com> wrote: > +1 (binding) > > Thanks Dan! > > On Mon, Mar 31, 2025 at 1:20 PM Ryan Blue wrote: > >> +1 >> >> On Mon, Mar 31, 2025 at 12:01 PM Anton Okolnychyi >> wrote: >> >>> +1 (binding) >>> >>> - Anton >>> >>> пн, 31 бер. 202

  1   2   3   4   5   >