Re: [VOTE] Release Apache PyIceberg 0.6.1rc1

+1 (non-binding) - Verified signatures and checksums - Verified license - Ran unit tests and integration tests Best regards, Honah On Tue, Apr 2, 2024 at 9:45 AM Honah J. wrote: > Hi Everyone, > > I propose that we release the following RC as the official PyIceberg 0.6.1 > release. > > This is

Re: truncate transform over binary columns

Another aspect that just occurred to me, there could be concern on just directly updating the spec as is since it's ultimately the source of truth (not the reference implementation). If there's concern that such a change would make other implementations technically non-compliant because they don't

Re: truncate transform over binary columns

Thanks for bringing this up Brian! In my view, the decision tree for this would look something like: 1.) Is there anything incorrect with supporting truncate on the basis of width for binary columns? I can't really think of any reason, it seems legitimate to me (handling characters outside of utf-

truncate transform over binary columns

Hello, this is my first time writing on this list so I'll introduce myself. I'm Brian Hulette, I've been involved with a couple of Apache projects in the past (Arrow and Beam), and now I'm working on BigQuery's support for Iceberg. My colleague raised an issue [1] a while ago about a discrepancy

Re: Materialized view integration with REST spec

I think we want to get clarity on the "combined object" approach. Some discussions are still going on. There is one particular thread that would benefit from some more clarification. Would

Re: Materialized view integration with REST spec

If there is consensus, great. We don't usually have a vote when there is already consensus. That said, I haven't really seen a confirmation that we have consensus, like a thread where people that originally had different perspectives all said they favored the same option. It can help to build clar

Community over Code EU 2024: Start planning your trip!

[Note: You're receiving this email because you are subscribed to one or more project dev@ mailing lists at the Apache Software Foundation.] Dear community, We hope you are doing great, are you ready for Community Over Code EU? Check out the featured sessions, get your tickets with special discoun

Participate in the ASF 25th Anniversary Campaign

Hi everyone, As part of The ASF’s 25th anniversary campaign[1], we will be celebrating projects and communities in multiple ways. We invite all projects and contributors to participate in the following ways: * Individuals - submit your first contribution: https://news.apache.org/foundation/entry

Re: Time-based partitioning on long column type

Hi Manu TIMESTAMP_LONG type promotion could be the easiest way, it would work with the existing transform. Would it work for you? Regards JB On Wed, Apr 3, 2024 at 5:56 AM Manu Zhang wrote: > > Hi all, > > We have source data with a timestamp field in LONG type to land in an Iceberg > table.

Re: Materialized view integration with REST spec

I thought we have a consensus in the doc at least on the possible option. I understood the vote was to adopt one of the options (that is possible for a vote). If we still need more discussion on the possible options or having a consensus on a specific option, it makes sense to continue the discuss