Re: [VOTE] Release Apache Iceberg 1.5.0 RC0

Hi Ryan, If it's "used" section is not strictly required in NOTICE from a legal perspective, the embedded dependencies should be mentioned (either under the Apache license as soon as they are not a ASF project), that's the "are not satisfied by either the text of LICENSE or the presence of licensi

Re: Materialized view integration with REST spec

Hi, Great to see more discussion on the MV spec. Actually, Jan's document "Iceberg Materialized View Spec" has been organized , with a "Design Questions" section to track these debates, and it would be nice to centr

Re: [VOTE] Release Apache Iceberg Rust 0.2.0 RC1

Hi, Ryan: >- The REST catalog was unable to resolve icebergdata.minio causing 2 >test failures. I had to switch over to local FS to run tests or else >rest_catalog_test cases test_create_table and test_update_table would fail. >I suspect this is a docker problem because there is a

Re: [VOTE] Release Apache Iceberg Rust 0.2.0 RC1

+1 (binding) - Checked signature and checksum - Ran the license check using docker run -it --rm -v $(pwd):/github/workspace apache/skywalking-eyes header check (I found this in the release.sh script) - Verified .licenserc.yaml, LICENSE, and NOTICE - Spot checked occurrences of ‘[

Re: Materialized view integration with REST spec

I think it would help if we answer the question of whether an MV is a view + storage table (and degree of exposing this underlying implementation) in the context of the user interfacing with those concepts: For the end user, interfacing with the engine APIs (e.g., through SQL), materialized view A

Re: Materialized view integration with REST spec

Hi Jack, > In my mind, the first key point we all need to agree upon to move this > design forward is*: Do we really want to go with the MV = view + storage > table design approach for Iceberg MV?* I think we want this to the extent that we do not want to redefine the same concept with differen

Re: Materialized view integration with REST spec

To address the specific question about MV = view + storage, I do feel that is the right approach. (The alternative would actually fit more cleanly with the "materialized table" concept, but there are a lot of reasons that probably isn't a great path to go down.) In many ways the materialized view

Re: Materialized view integration with REST spec

I suggest we need a step-by-step process to make incremental consensus, otherwise we are constantly talking about many different debates at the same time. In my mind, the first key point we all need to agree upon to move this design forward is*: Do we really want to go with the MV = view + storage

Re: Materialized view integration with REST spec

Jack, I think we should consider either allowing the storage table to be fully exposed/addressable via the catalog or allow access via namespacing like with metadata tables. E.g. ..., which would allow for full access to the underlying table. For other engines to interact with the storage table

[ANNOUNCE] Apache PyIceberg release 0.6.0

I'm pleased to announce the release of Apache PyIceberg 0.6.0! 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. Th

Re: [VOTE] Release Apache Iceberg Rust 0.2.0 RC1

+1 (binding) Verified checksum, signature, license, note, ASF header Ran build and test Checked no unexpected binary files Best, Jack Ye On Mon, Feb 19, 2024 at 2:33 AM Jean-Baptiste Onofré wrote: > +1 (non binding) > > I checked: > - checksum and signature are correct > - ASF headers are ther

Re: [VOTE] Release Apache PyIceberg 0.6.0rc6

Thanks everyone for voting! The 72 hours have passed, and a minimum of 3 binding votes have been cast: +1 Ryan Blue (binding) +1 Daniel Weeks (binding) +1 Amogh Jahagirdar (non-binding) +1 Honah J. (non-binding) +1 Hussein Awala (non-binding) +1 Fokko Driesprong (binding) +1 Jack Ye (binding) Th

Re: Process for creating new Proposals

> > I don't think there should be a vote on individual features as these are > best discussed in the specification document. In my mind there is a distinction between a voting and discussion. I agree that discussion is probably best served on the document. I see voting as a final notice that th

Re: [VOTE] Release Apache PyIceberg 0.6.0rc6

+1 (binding) Checked signature, checksum, license Ran unit and integ tests with Python 3.11 Ran manual tests with Glue catalog Best, Jack Ye On Mon, Feb 19, 2024 at 4:35 AM Fokko Driesprong wrote: > +1 (binding) > > I've checked signatures and checksums, checked the licenses, and did some > c

Re: [VOTE] Release Apache Iceberg 1.5.0 RC0

JB, Can you help me understand your rationale for updating NOTICE? We are strict about what goes into the NOTICE file to comply with ASF guidance : The NOTICE file is reserved for a certain subset of legally required notifications which ar

Re: [VOTE] Release Apache Iceberg 1.5.0 RC0

Hi Eduard Thanks for the update. I agree that it's a blocker, so +1 to go with a RC1. Regards JB On Mon, Feb 19, 2024 at 5:25 PM Eduard Tudenhoefner wrote: > > I noticed an issue while upgrading to the latest Iceberg version internally > and in Trino. As part of #9012 I've added a check when a

Re: [VOTE] Release Apache Iceberg 1.5.0 RC0

I noticed an issue while upgrading to the latest Iceberg version internally and in Trino. As part of #9012 I've added a check when a new table is being created that makes sure a view with the same name doesn't exist. The unintentional side-effect of thi

Re: [VOTE] Release Apache PyIceberg 0.6.0rc6

+1 (binding) I've checked signatures and checksums, checked the licenses, and did some checks around writing. Kind regards, Fokko Op ma 19 feb 2024 om 03:07 schreef Amogh Jahagirdar : > +1 non-binding > Verified signatures, checksum, and license > Ran unit/integ tests on Python 3.10.4 > Ran ad-

Re: [VOTE] Release Apache Iceberg Rust 0.2.0 RC1

+1 (non binding) I checked: - checksum and signature are correct - ASF headers are there (not in the tsv files but not a problem) - no binary found in the source distribution Good improvement for next releases: update NOTICE file to mention non ASF dependencies (listed in DEPENDENCIES.rust.tsv) w

Re: [VOTE] Release Apache Iceberg 1.5.0 RC0

+1 (non binding) I checked: - checksum and signature are correct - ASF headers are OK - no binary found in the source distribution - build is OK from the source distribution To be improved for next releases (not blocker at all): - NOTICE file should mention dependencies and tools used (not necess

[VOTE] Release Apache Iceberg 1.5.0 RC0

Hi Everyone, I propose that we release the following RC as the official Apache Iceberg 1.5.0 release. The commit ID is bff665278245128a71982ba5ac5981a9e71c4509 * This corresponds to the tag: apache-iceberg-1.5.0-rc0 * https://github.com/apache/iceberg/commits/apache-iceberg-1.5.0-rc0 * https://gi

Re: Dynamically Support Spark Native Engine in Iceberg

Thanks, it works now. On Mon, Feb 19, 2024 at 2:56 PM huaxin gao wrote: > Hi Renjie, > I have modified the google doc setting to allow commenting. Could you try > again when you have time? > > Thanks, > Huaxin > > > On Sun, Feb 18, 2024 at 6:13 PM Renjie Liu > wrote: > >> Hi, huaxin: >> >> Than