Re: [DISCUSS] Additional language implementations for Iceberg Puffin reader/writer

Hi: I think it is reasonable to start a new C++ sub-project even if it will > only contain Puffin writers/readers initially. Are there any alternatives? > We could add a separate repo for Puffin but we previously concluded it is > not a good idea to support multiple languages in one repo. I'm no

[DISCUSS] PyIceberg 1.0.0 Release

Hi folks, With the recent releases, the interest in PyIceberg has been growing at a very exciting speed: https://pypistats.org/packages/pyiceberg. And this got me thinking about the roadmap for a 1.0.0 release. Looking up for guidelines for "when to make a 1.0.0 release", the answer on semver.org

Re: [DISCUSS] Additional language implementations for Iceberg Puffin reader/writer

I definitely support the idea of having Puffin readers/writers for different languages managed by the community. It would be really unfortunate for engines to re-implement this logic. Like Piotr said, it is not only for V3 position deletes but also for table stats supported today. I think it is re

Re: [DISCUSS] Iceberg Materialzied Views

Hi Jan, I think we need to close the discussion on the UUID vs table identifier options and possibly cast a vote before having a productive discussion on the PR. I did not get a chance yet to post the document on the UUID vs table identifier discussion. I will do that by next week. Thanks, Walaa.

Re: [DISCUSS] Row Lineage Proposal

+1 for making row lineage and equality deletes mutually exclusive. The idea behind equality deletes is to avoid needing to read existing data in order to delete records. That doesn't fit with row lineage because the purpose of lineage is to be able to identify when a row changes by maintaining an

Re: [DISCUSS] Additional language implementations for Iceberg Puffin reader/writer

Hi, It won't be an issue if there is already an iceberg-cpp implementation. However, it is unfortunate to see duplicate efforts from different query engines to implement their own C++ Iceberg reader and writers. Is it a good chance to add official C++ implementation by providing a puffin reader/wr

Re: [VOTE] Merge REST Spec change to add RemovePartitionSpecsUpdate update type

+1 (binding) On Wed, Aug 28, 2024 at 8:33 AM Jack Ye wrote: > +1 (binding) > > On Tue, Aug 27, 2024 at 5:21 AM roryqi wrote: > >> +1 >> >> Manu Zhang 于2024年8月27日周二 11:44写道： >> >>> +1 (non-binding) >>> >>> On Tue, Aug 27, 2024 at 11:00 AM xianjin wrote: >>> +1 (non-binding) Sent from

Re: [VOTE] Merge guidelines for committing PRs

-0 While I appreciate the motivation, I think that this is going to lead to more problems, not fewer. On Wed, Aug 28, 2024 at 10:54 PM Renjie Liu wrote: > +1 (binding) > > On Thu, Aug 29, 2024 at 8:59 AM Amogh Jahagirdar <2am...@gmail.com> wrote: > >> +1 (binding) >> >> On Wed, Aug 28, 2024 at

Re: [DISCUSS] Additional language implementations for Iceberg Puffin reader/writer

Hi Gabor, thanks for starting this topic. it would be awesome to have Puffin readers/writers available to all languages supported by the Iceberg community! The topic is important for v3, but also if we want to support stats updates when writing to tables that already have some stats collected. i

Re: [DISCUSS] DROP PARTITION in Spark

Thanks for the answers! Sorry, I didn't drop the subject I just had other priorities too but still find this topic interesting to discuss. Understood, DROP PARTITION can't happen. *Thanks Anton* for showing some interest and sharing some alternatives! I checked the canDeleteWhere() and canDeleteU

[DISCUSS] Additional language implementations for Iceberg Puffin reader/writer

Hi Iceberg Community, With the V3 position delete proposal it came up that non-Java engines might have to implement a Puffin reader and writer themselves so that they can support the newly proposed position deletes.

[DISCUSS] Iceberg Materialzied Views

Hi all, to move the Iceberg Materialzied View Proposal forward, I created a PR (https://github.com/apache/iceberg/pull/11041) that adds a section on Materialized Views to the View Spec. I hope we can resolve any remaining questions there, before we can start the voting process for the Proposal

Re: [DISCUSS] iceberg-rust: pyiceberg_core 0.1.0 Release

> > OpenDAL tends to release all packages simultaneously but with different > versions. We can try this approach as well. I think it's a good approach. But I also agree that we could release pyiceberg_core separately for now, and rethink the workflow when we actually have more bindings. On Thu,

Re: Request to Add RisingWave to Apache Iceberg Documentation

Hi, Alice Welcome to join in the iceberg community! The RisingWave Team contributes a lot for the iceberg-rust project. Feel free to submit a PR so the community can continue the discussion there. A small note: Please avoid referring to RisingWave as "Apache RisingWave" as it might give the i