Hi Dan, Thanks for the feedback.
For Drop/Recreate, as long as we verify the UUID is still current (i.e.,
the table in the catalog still maintains the same UUID as in the one in the
lineage), we can assume the table is not dropped and recreated. Once it is
dropped or recreated, the UUID in the cat
Hi all,I would like to mention that Walaa's document doesn't mention any downsides of Approach #1 in the comparison.Approach #1 has downsides when views are referenced in the materialized view query. These problems arise because only direct children are stored in the lineage. This leads to:- The li
I'm generally in favor of approach #1 with UUID in lineage.
I think it's helpful to know if the underlying table changes (e.g.
identifier remains the same, but the table was changed). However, I'm not
sure what the behavior would be in that case. Any refresh at that point
would not be able to pr
+1
I think it would be good to give an overview of the current proposal since
it has evolved quite a bit from the original like Jack said.
On Tue, Sep 3, 2024 at 9:09 AM Jack Ye wrote:
> Thanks for keeping pushing for this Rahil. Personally I am +1 (binding)
> for this, with just some minor com
The vote passes:
5 +1 Binding Votes (Steven, Anton, Yufei, Amogh, Renjie)
3 +1 non-binding votes (Walaa, Dmitri, Micah)
2 -0 (Ryan and JB)
I think the next step is to merge the PR [1] , could a committer help with
this?
Thanks,
Micah
[1] https://github.com/apache/iceberg/pull/10780
On Fri, Aug
Hi Steven,
Thanks! I see the PR now introduces UUID in the state information. That is
great progress. I still have slight preference on where to place UUID (in
lineage vs state), which I summarized in this doc [1] as promised. I wrote
the doc before UUID was added in the PR, so it still compares w
Walaa, for the listed discussion points, how should we move forward? should
we have another MV sync meeting?
BTW, Jan's latest spec PR addressed my comment on UUID.
On Mon, Sep 2, 2024 at 4:35 PM Walaa Eldin Moustafa
wrote:
> Hi Jan,
>
> I think we need further discussion for a few reasons:
>
>
Thanks for keeping pushing for this Rahil. Personally I am +1 (binding) for
this, with just some minor comments in the latest PR.
But I think the initial DISCUSS thread [1] was quite a while ago and a lot
has changed after a lot of comments and reviews. Should we restart another
DISCUSS thread bef
