New Release Candidate was made and a new vote started! Thanks everyone,
let's do this again
On Mon, Nov 4, 2024 at 11:06 AM Russell Spitzer
wrote:
> https://github.com/apache/iceberg/pull/11462 <- For Main, I created a
> branch for 1.7.x off of RC0 which I will backport the fix to after we merge
Hi y'all!
I propose that we release the following RC as the official Apache Iceberg
1.7.0 release.
The commit ID is 5f7c992ca673bf41df1d37543b24d646c24568a9
* This corresponds to the tag: apache-iceberg-1.7.0-rc1
* https://github.com/apache/iceberg/commits/apache-iceberg-1.7.0-rc1
*
https://githu
https://github.com/apache/iceberg/pull/11462 <- For Main, I created a
branch for 1.7.x off of RC0 which I will backport the fix to after we merge
to main.
On Mon, Nov 4, 2024 at 10:26 AM Russell Spitzer
wrote:
> Sounds good to me. I'll work on that this morning
>
> On Mon, Nov 4, 2024 at 10:16 A
For reference, there are two reasons why I chose to add that substrait.go:
1) The Golang Arrow implementation has a compute package which is able to
evaluate substrait expressions as long as the kernels exist in the package.
2) Along the lines of this conversation, I wanted to be able to generica
Matt also just added `substrait.go` to the Iceberg-Go implementation that I
was reviewing today:
https://github.com/apache/iceberg-go/pull/185/files#diff-81cfac9f2e1dcf6265c569d0a3397964f0b78e07f45bb9dcdd3effe0623aaf73
That converts an Iceberg expression into a substrate one, pretty exciting
stuff
Well, it seems like I'm a little late, so most of the arguments are voiced.
I agree that we should not deprecate the equality deletes until we have a
replacement feature.
I think one of the big advantages of Iceberg is that it supports batch
processing and streaming ingestion too.
For streaming in
Sounds good to me. I'll work on that this morning
On Mon, Nov 4, 2024 at 10:16 AM Amogh Jahagirdar <2am...@gmail.com> wrote:
> Thanks for identifying this issue and bringing it up here Cheng, that's
> really appreciated! @Russell Spitzer I do
> think it is an issue, if I understand the issue cor
Thanks for identifying this issue and bringing it up here Cheng, that's
really appreciated! @Russell Spitzer I do think
it is an issue, if I understand the issue correctly, there are certain
cases in 1.14.3 where we may not be reading the dictionary filter in its
entirety, leading to correctness i
We are currently including 1.14.3 as a build dependency, is that an issue?
On Sun, Nov 3, 2024 at 12:47 PM Cheng Pan wrote:
> FYI, I just identified a Parquet data loss issue(newly introduced in
> 1.14.0), and I confirmed it affects the Spark use cases, I’m not sure if it
> also affects Iceberg
Here you go,
https://github.com/apache/iceberg/compare/apache-iceberg-1.6.1...apache-iceberg-1.7.0-rc0
On Mon, Nov 4, 2024 at 9:40 AM Manu Zhang wrote:
> +1 (non-binding)
> Build with JDK17 and test with SparkCatalog / SparkSessionCatalog (type
> hive) on Spark 3.5.0.
>
> BTW, according to
> htt
+1 (non-binding)
Build with JDK17 and test with SparkCatalog / SparkSessionCatalog (type
hive) on Spark 3.5.0.
BTW, according to
https://iceberg.apache.org/how-to-release/#validating-a-source-release-candidate
,
release announcement should include links to GitHub change comparison?
On Mon, Nov
+1 (binding)
Verified signature/checksum/license and build/test with JDK17
On Mon, Nov 4, 2024 at 1:15 AM Honah J. wrote:
> +1 (binding)
>
> Verified signature/checksum/license/build/test with JDK17
>
> Best regards,
> Honah
>
> On Sun, Nov 3, 2024 at 10:47 AM Cheng Pan wrote:
>
>> FYI, I jus
Hi Ajantha,
During CommunityOverCode, I chatted with Matt Topol about Substrait and ADBC.
I checked the Substrait support in DataFusion and it's interesting.
I was thinking about where to actually store the Substrait plan (I was
thinking about an intermediate SQL representation that we could stor
Thanks everyone for the detailed discussions.
Looks like we have consensus towards Substrait.
Last time I checked it was not adopted by all the engines. But we can work
towards the adoption as well.
I will explore further on Substrait and come up with the design doc on the
same.
Thanks,
Ajantha
Hi Christian
Nice document, thanks !
Definitely a great idea to "document" the OAuth2 flow. My only comment
is that we should document the client side (what you are doing great
in the doc), but also the server side (it might help to understand the
full picture).
I propose to have a group effort o
Hi Rocco
Thanks for bringing this discussion.
In the context of multiple languages support (python, rust, go, java,
...), I'm more in favour of 1 (updating the docs).
Implementations can deal with that.
Regards
JB
On Thu, Oct 31, 2024 at 6:40 PM Rocco Varela wrote:
>
> Hi everyone,
>
> Apologi
16 matches
Mail list logo
