Hi Walaa,
in my opinion the UUID vs table identifier discussion comes down to the
question: do we introduce table identifiers in an opaque struct in the
table snapshot summary or do we accept technical drawbacks?
Using UUIDs with a lineage struct in the view metadata leads to one of
the following drawbacks:
- If we don't fully expand the query tree in the lineage, we have to
expand the lineage on every read to determine freshness
- If we fully expand the query tree in the lineage, the view version
must be updated every time a child view changes
With table identifiers we don't have any technical drawbacks. The fact
that the query tree has to be expanded for the refresh operation is not
a drawback, as this also has to be done for UUIDs with a not fully
expanded query tree.
Again, the question comes down to: do the technical drawbacks outweigh
introducing table identifiers in the table snapshot summary?
In my opinion yes. And if I understand correctly, most of the other
people participating in the discussion have a similar stance.
I'm not sure if we really need another document for the discussion.
Best wishes,
Jan
On 29.08.24 21:10, Walaa Eldin Moustafa wrote:
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.
On Thu, Aug 29, 2024 at 5:31 AM Jan Kaul <jank...@mailbox.org.invalid>
wrote:
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.
It would be great if you could have a look.
Best wishes,
Jan
