;t feel like it's a good idea
> to capture data in the view that we may allow to drift if there isn't any
> requirement that they match. This also aligns with the identifier
> resolution being late binding.
>
> -Dan
>
> On Wed, May 7, 2025 at 10:45 PM Walaa Eldin Mousta
bles/views with UUIDs. View
> consumers can validate resolved tables/views with the stored UUIDs and fail
> the query if mismatch.
>
> The UUID change doesn't really change the table identifier resolution rule
> though. It is more of a safety protection.
>
> On Wed, May 7, 202
> namespace. This affects both where the view is created and how unqualified
>> table identifiers are resolved. I also don't see an issue with saving the
>> current catalog and namespace into the view metadata's default-catalog and
>> default-namespace fields.
&g
ld). The proposal is suggesting to get
out of this space and let engines handle it similar to how they handle all
identifiers.
On Wed, Apr 30, 2025 at 5:07 PM Walaa Eldin Moustafa
wrote:
> > I thought "default-catalog" could be set via the USE command.
>
> Benny, I th
query validation time if identifiers
> need to be looked up from a bunch of places. Hopefully, it should be
> possible to define a view in such a way that identifiers can be resolved on
> the first try.
>
> Benny
>
> On Tue, Apr 29, 2025 at 10:29 PM Walaa Eldin Moustafa <
&
esolution rule.
>
>
> Thanks,
> Rishabh
>
> On Mon, Apr 28, 2025 at 3:22 PM Walaa Eldin Moustafa <
> wa.moust...@gmail.com> wrote:
>
>> Correction of typo: both engines seem to set default-catalog to the view
>> catalog if it is defined, or to null if the view
Correction of typo: both engines seem to set default-catalog to the view
catalog if it is defined, or to null if the view catalog is not defined.
On Mon, Apr 28, 2025 at 3:06 PM Walaa Eldin Moustafa
wrote:
> Hi Dan,
>
> Thanks again for your response.
>
> I agree that catalog
behavior
> when you start altering the environment around it, which isn't something we
> should be trying to define here.
>
> -Dan
>
> On Mon, Apr 28, 2025 at 12:17 PM Walaa Eldin Moustafa <
> wa.moust...@gmail.com> wrote:
>
>> Hi Dan,
>>
>> Thanks
; or the "view catalog" should be used? This way, you could
>> use the "default-catalog" in environments where you can guarantee
>> consistent naming, but you would be able to directly fallback to the
>> "view-catalog" when you don't have consistent na
stored metadata.
* Store UUIDs alongside table identifiers whenever possible.
Thanks,
Walaa.
On Fri, Apr 25, 2025 at 5:18 PM Walaa Eldin Moustafa
wrote:
> Thanks for the contribution Benny! +1 to the confusion the fallback
> creates. Also just to be clear, at this point and after cl
ould extend Russell's idea to allow identifiers in a view to span
> catalogs to support non-Iceberg tables. Also, the default-catalog
> property could be templated as well.
>
> Thoughts?
> Benny
>
>
>
> On Fri, Apr 25, 2025 at 4:02 PM Walaa Eldin Moustafa <
> wa
ntation issue for not conforming
> to the spec.
>
>
> On Fri, Apr 25, 2025 at 1:17 PM Walaa Eldin Moustafa
> wrote:
> >
> > Hi Jan,
> >
> > Thanks again for continuing the discussion. I want to highlight a few
> fundamental issues around the interpretation of d
t-catalog isn't defined, since the
>> view hasn't been created or loaded yet?
>
> I don't think this is related to view spec. How do we validate that a
> table exists without a default catalog, or do we always use the current
> session catalog?
>
> Thanks,
>
on to all partial table references when no
> "default-catalog" is present. Resolving the view catalog name at query time
> is not opposed to storing the view metadata in a catalog.
>
> Or maybe I don't entirely understand what you mean.
>
> Thanks
>
> Jan
red to resolve the
> table identifiers is contained in the view metadata (and the "view
> catalog"). I think that if you make the identifier resolution dependent on
> external parameters, it hinders portability.
>
> Thanks,
>
> Jan
> On 4/22/25 18:36, Walaa Eldin Moust
r "default-catalog" because
> it is more deterministic in my opinion. And I think the current spec does a
> good job for multi-engine table identifier resolution. I see the UUID
> validation more of an additional hardening strategy.
>
> Thanks
>
> Jan
> On 4/21/25 17:38,
+1 to the direction (non-binding).
Left some clarification comments on the PR.
Thanks,
Walaa.
On Mon, Apr 21, 2025 at 10:57 PM Manu Zhang wrote:
> +1 (non-binding) except for some ambiguity between struct field and fields
> within struct (Russell already made a nice suggestion).
>
> Thanks,
>
store resolved table uuid in view
> metadata, as table/view renaming may introduce errors that's difficult to
> understand for user.
>
> On Sat, Apr 19, 2025 at 3:02 AM Walaa Eldin Moustafa <
> wa.moust...@gmail.com> wrote:
>
>> Hi Everyone,
>>
>> Look
-namespace are handled (defaulting both to the session context
if not explicitly set) to better align with engine behavior and improve
cross-engine interoperability.
Please let me know your thoughts.
Thanks,
Walaa.
On Wed, Apr 16, 2025 at 2:03 PM Walaa Eldin Moustafa
wrote:
> Thanks Eduard and S
..@apache.org> wrote:
>
>> Thanks Walaa for tackling this problem. I've added a few comments to get
>> a better understanding of how this will look like in the actual
>> implementation.
>>
>> Eduard
>>
>> On Tue, Apr 15, 2025 at 7:09 PM Walaa El
Hi Everyone,
Starting this thread to resume our discussion on how to reference table
identifiers from Iceberg metadata, a key aspect of the view specification,
particularly in relation to the MV (materialized view) extensions.
I had the chance to speak offline with a few community members to bett
Thanks Manu for starting this discussion. That is definitely a valid
feature. I have always found maintaining snapshots by day makes it harder
to provide different types of guarantees/contracts especially when tables
change rates are diverse or irregular. Maintaining by snapshot count makes
a lot o
Hi Ryan,
For Table Format V3, we could point out that the default value support for
Avro has been merged and support for other formats is ongoing.
Thanks,
Walaa.
On Wed, Dec 11, 2024 at 12:51 PM rdb...@gmail.com wrote:
> Hi everyone,
>
> It’s time to report to the board again. Great to see al
gt;> work with the respective IR community to help close those gaps or if needed
>>> consider other paths.
>>> >>
>>> >> Thanks,
>>> >> Amogh Jahagirdar
>>> >>
>>> >> On Mon, Oct 28, 2024 at 11:43 AM Piotr Fin
t;> on how to resolve this. If needed, we can schedule another online meeting
>> to discuss in person.
>>
>> Best regards, Jan
>>
>> 1.
>> https://lists.apache.org/list?dev@iceberg.apache.org:lte=1M:view%20spec%20improvements
>> On 14.10.24 23:31, Walaa
a
> dataframe-based world. Walaa, do you have any outlook on Coral
> Python/Rust/Go support?
>
> Kind regards,
> Fokko
>
>
> Op vr 25 okt 2024 om 22:16 schreef Walaa Eldin Moustafa <
> wa.moust...@gmail.com>:
>
>> I think this may need some more discussion.
I think this may need some more discussion.
To me, a "serialized IR" is another form of a "dialect". In this case, this
dialect will be mostly specific to Iceberg, and compute engines will still
support reading views in their native SQL. There are some data points on
this from the Trino community
Hi Everyone,
Thanks for all the discussion so far. I have created a PR to document the
requirements https://github.com/apache/iceberg/pull/11365. Please feel free
to review it or discuss further in the thread.
Thanks,
Walaa.
On Fri, Oct 11, 2024 at 5:19 PM Walaa Eldin Moustafa
wrote:
>
es set depending on the
> USE context. If Dremio intended for that view to be readable by Spark, it
> would have to adhere to all those restrictions I listed before.
>
> Thanks
> Benny
>
> On Fri, Oct 11, 2024 at 10:00 AM Walaa Eldin Moustafa <
> wa.moust...@gmail.
Benny, "Iceberg View Spec Improvements" includes documenting what is
supported and what is not. You listed a few restrictions. Many of them are
not documented on the current spec. Documenting them is what this thread is
about. We are trying to reach a consensus on the necessary constraints (so
we a
sing to people, I would be open to
>> discussing an "unsupported configurations" callout, but I don't think this
>> blocks work and am somewhat skeptical that it's necessary.
>>
>> -Dan
>>
>>
>>
>> On Thu, Oct 10, 2024
onfusing to people, I would be open to
> discussing an "unsupported configurations" callout, but I don't think this
> blocks work and am somewhat skeptical that it's necessary.
>
> -Dan
>
>
>
> On Thu, Oct 10, 2024 at 2:47 PM Walaa Eldin Moustafa <
&g
Hi Dan,
I think there are a few questions that we should solve to decide the path
forward:
** Does the current spec contain implicit assumptions?*
I think the answer is yes. I think this is also what Ryan indicated here
[1].
** Do these implicit assumptions make it difficult to adopt the spec or
Thanks Ryan and everyone who left feedback on the doc. Let me clarify a few
things.
"Improving the spec" also includes making the implicit assumptions
explicitly stated in the spec.
Explicitly stating the assumptions is discussed under the "Portable table
identifiers" section in the doc. I am onb
uld be
> consistent across engines. catalog federation can achieve the
> normalization/standardization of the catalog names
>
>
>
> On Tue, Oct 8, 2024 at 6:17 PM Walaa Eldin Moustafa
> wrote:
>
>> Just opened Comment access to the doc. Link here again for convenience
&g
Just opened Comment access to the doc. Link here again for convenience [1].
[1]
https://docs.google.com/document/d/1e5orD_sBv0VlNNLZRgUtalVUllGuztnAGTtqo8J0UG8/edit
Thanks,
Walaa.
On Tue, Oct 8, 2024 at 10:42 AM Walaa Eldin Moustafa
wrote:
> Thanks Steven! I think this fits in the framew
d in a federated catalog. the references to source tables should
> include the source catalog names, which are standardized by the federated
> catalog.
>
> Thanks,
> Steven
>
>
> On Mon, Oct 7, 2024 at 11:16 PM Walaa Eldin Moustafa <
> wa.moust...@gmail.com> wrote:
&g
Hi Everyone,
As part of our discussions on the Materialized View (MV) spec, the topic of
"SQL table identifiers" has been a constant source of complexity. After
several iterations, the community has agreed not to use SQL table
identifiers in the table-side representation of MVs. However, that stil
Hi Russel,
I am not sure if materialized views change the table spec. Table spec
remains largely the same when it comes to handling MVs. Further, I think
there may be unresolved questions on the view part before proceeding with
the MV spec (namely on catalog names).
There is also a PR on default
be based on *engine agnostic*
>>> identifiers without the catalog name. The MV and storage table would have
>>> to be in the same catalog.
>>>
>>> Thanks
>>> Benny
>>>
>>>
>>>
>>> On Fri, Sep 13, 2024 at 2:08 AM Jan Kaul
t make sense then to store the lineage as part of the
>> representation:
>>
>> {
>>
>> "type": "sql",
>>
>> "sql": "SELECT\n COUNT(1), CAST(event_ts AS DATE)\nFROM events\nGROUP
>> BY 2",
>>
>>
ons like RTAS or Drop/Create on tables
> referenced by a view, #1 might not work. My understanding is that most
> database systems wouldn't allow that, but it could also be hard to enforce
> without a more complicated catalog implementation.
>
> -Dan
>
> On Tue, Sep 3, 2024 at
sed 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:
>>
>> * Semantic issues are significant, especially in a spec. They could
>> create gaps that
> 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
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.
+1 (non-binding)
On Wed, Aug 28, 2024 at 9:36 AM Steven Wu wrote:
> +1 (binding)
>
> On Wed, Aug 28, 2024 at 9:29 AM Micah Kornfield
> wrote:
>
>> I propose to merge https://github.com/apache/iceberg/pull/10780 as a
>> starting place for describing community norms around merging/discussing PRs.
d. You
> would still be able to determine the freshness of the precomputed data.
>
> Thanks,
>
> Jan
> On 20.08.24 18:53, Walaa Eldin Moustafa wrote:
>
> Theoretically, we could have multiple catalogs each with different table
> name entries but referring to the same Ic
+1 non-biding
Thanks for driving this Eduard.
On Tue, Aug 20, 2024 at 12:17 PM Daniel Weeks wrote:
> +1
>
> On Tue, Aug 20, 2024 at 11:19 AM Yufei Gu wrote:
>
>> +1
>>
>> Yufei
>>
>>
>> On Tue, Aug 20, 2024 at 11:16 AM Eduard Tudenhöfner <
>> etudenhoef...@apache.org> wrote:
>>
>>> Hey everyon
the table and view versions at the time of
> materialization. Directly using table identifiers seems pretty natural to
> me. So, I'm +1 for:
>
> no lineage
> + refresh-state key = identifier
>
> Thanks
> Benny
>
>
>
> On Mon, Aug 19, 2024 at 9:19 P
could be handled if it proves to be a problem but hopefully engines are
> placing a reasonable cap on view depth + number of tables per view which
> puts an upper bound on overall size.
>
> Thanks,
> Micah
>
> On Fri, Aug 16, 2024 at 4:56 PM Walaa Eldin Moustafa <
> wa.mou
re are several exceptions to this process:", but it was not clear what
>> process/which part of it. Hence, being more direct could simplify parsing
>> these two paragraphs.
>
>
> I have tried to remove the ambiguity on the "this process". For anything
> not add
ineage in the view as a nice-to-have.
>
>
> I think if lineage is introduced to the View metadata, it should only hold
> direct dependencies for the reasons already discussed. IMO, I think the
> potential overlap is OK as they serve two different purposes.
>
> Cheers,
> Micah
&
o fully expand the query tree.
>
> Best wishes,
>
> Jan
>
> Am 16.08.2024 18:13 schrieb Walaa Eldin Moustafa :
>
> Thanks Jan for the summary.
>
> For this point:
>
> > For a refresh operation the query engine has to parse the SQL and fully
> expand t
; currently in the state map), without reparsing the view tree.
>
> For a refresh operation the query engine has to parse the SQL and fully
> expand the lineage with it's children anyway. So the lineage is not
> strictly required.
>
> If I understand correctly, most of you are
Thank you Eduard for sharing this version of the proposal. Looks simple,
functional, and extensible.
On Thu, Aug 15, 2024 at 1:10 PM Ryan Blue
wrote:
> I think I'm fine either way. I lean toward the simplicity of the strings
> in the proposal but would not complain if we went with Yufei's sugges
the MV and
>> possibly additional views to reconstruct the lineage map. It's just a lot
>> slower and more work for the engine when there is a MV that references a
>> lot of views (and those views reference additional views).
>>
>> Thanks
>> Benny
>
are making is that every id that is used in the
>>>> refresh-state has to be defined in the lineage.
>>>> So the question about using uuids is rather, can the query engine trust
>>>> that the id defined in the lineage is the uuid of the table.
>>>>
>&
Thanks Benny. For refs, I am +1 to represent them as UUID + optional ref,
although we can iterate ohe exact JSON structure (e.g., another option is
splitting for (UUID) state from (UUID + ref) state into two separate
higher-level fields).
Generally agree on REFRESH VIEW strategy could be up to the
, Aug 8, 2024 at 4:43 PM Walaa Eldin Moustafa
wrote:
> Thanks Benny! We discussed this option during the meeting but we did not
> prefer it because we did not want to leak the SQL identifiers to the
> storage table since SQL identifiers are view concepts and fit better with
> the view
I think the issue with the first paragraph is about:
1- The perceived contradiction between a) trusting committers to act in the
best interest of the project and b) simultaneously providing specific
guidelines on how to act (e.g., by avoiding conflicts of interest).
2- The specific examples given
a process that guides both the contributor and committer for
>>>>> what qualifies as proposal vs a direct PR).
>>>>
>>>>
>>>> If I am understanding correctly, this is saying more guidelines for
>>>> what should go through th
also capture the view lineage. So, what I am suggesting is that we
> do both but not couple them together through any sort of sequence ID or
> UUID.
>
> Thanks
> Benny
>
> On Thu, Aug 8, 2024 at 2:04 PM Walaa Eldin Moustafa
> wrote:
>
>> Hi Everyone,
>>
>> In th
Hi Everyone,
In the last community sync on Materialized Views [1], we agreed to split
the information that is used to determine the materialized view staleness
to two parts: Lineage Information and State Information. We have made a lot
of progress on representing both but one issue remains open:
eview on this.
>>>
>>> We didn't find any blocker for the spec.
>>> I will wait for a week and If no more review comments, I will raise a PR
>>> for spec addition next week.
>>>
>>> If anyone else is interested, please have a look at the proposa
Catching up here.
>From Eduard's doc [1], it seems that at the end of the day, the
capability boils down to whether an end point is implemented by the
server or not. Therefore, I feel we could simplify things by skipping
the categorization/grouping (e.g., tables, views, udfs, etc) and just
allow s
My concern with this change (in its current form) is that it combines
(mixes?) three things:
[1] A few paragraphs/statements that delegate to the comitter's
judgement call. (e.g., "Committer is trusted", "If committer feels"
..). So the value of adding them is not very clear to me.
[2] A few thing
Another feature that was planned for V3 is support for default values.
Spec doc update was already merged a while ago [1]. Implementation is
ongoing in this PR [2].
[1] https://iceberg.apache.org/spec/#default-values
[2] https://github.com/apache/iceberg/pull/9502
Thanks,
Walaa.
On Wed, Jul 31,
Congratulations everyone! Great to see the community growing.
Thanks,
Walaa.
On Tue, Jul 23, 2024 at 8:51 AM Alex Dutra
wrote:
> Congratulations to you all!
>
> Thanks,
> Alex
>
> On Tue, Jul 23, 2024 at 5:30 PM Jack Ye wrote:
>
>> Congratulations!!
>>
>> Best,
>> Jack Ye
>>
>> On Tue, Jul 23,
Hi Jean, One use case is Hive to Iceberg migration, where DROP PARTITION
does not need to change to DELETE queries prior to the migration.
That said, I am not in favor of adding this to Iceberg directly (or
Iceberg-Spark) due to the reasons Jean mentioned. It might be possible to
do it in a custom
gt;
>>> Hi All,
>>> Please find the proposal link
>>> https://github.com/apache/iceberg/issues/10432
>>>
>>> Google doc link is attached in the proposal.
>>> And Thanks Stephen Lin <https://github.com/sxlin> for working on it.
>>>
Hi Yufie,
The original proposal did not seem to indicate that the metadata tables
will be "materialized" (outside regular Iceberg metadata since most of
those metadata tables are actually "views" on Iceberg metadata). However,
in the last response, it seems metadata could potentially be written to
Hi Szehon,
Thanks for sharing this proposal. We have thought along the same lines and
implemented an external system (LakeChime [1]) that retains snapshot +
partition metadata for longer (actual internal implementation keeps data
for 13 months, but that can be tuned). For efficient analysis, we ha
Thanks, Jack, for taking the time to put this initiative together.
I will borrow Julian Hyde’s example of the blind men and the elephant [1]:
“Do you know the story of the blind men and the elephant? Each man touches
a different part of the elephant, so they assume they are touching a
different a
n on top of 100 tables (possibly a mix of Iceberg and
> non-Iceberg) and you know that the refresh job ran on say 6/20/2024
> 12:02:10 UTC, then whatever data is in the materialization has to be "fresh
> as of" 6/20/2024 12:02:10 UTC.
>
> Thanks
> Benny
>
>
>
&
Benny, is the suggestion to couple the "refresh-start-timestamp-ms"
property with a grace period as well? Also, could you clarify which
timestamp "refresh-start-timestamp-ms" refers to:
(1) Timestamp when refresh is triggered
(2) Timestamp when refresh is concluded and the snapshot is written.
Als
me open comments that are not relevant anymore due to the
> changes, please close them so that we can clean up the comments section a
> bit.
>
> Regards,
>
> Jan
> On 07.06.24 08:33, Walaa Eldin Moustafa wrote:
>
> * lineage state JSON structure
>
> On Thu, Jun 6, 2024
Thanks Jack and team for working on this proposal. I went over it and it is
very well written. I particularly like:
(1) The fact that it is adopting the SQL standard and adjusting some of its
semantics to fit the Iceberg model.
(2) It includes views from v1. Views are a very important tool for po
* lineage state JSON structure
On Thu, Jun 6, 2024 at 11:31 PM Walaa Eldin Moustafa
wrote:
> Hi Benny,
>
> Your understanding is correct.
>
> Another point that we discussed was the type of APIs engines can use to
> conveniently update the storage table with view query result
Hi Benny,
Your understanding is correct.
Another point that we discussed was the type of APIs engines can use to
conveniently update the storage table with view query results as well as
set the snapshot summary on the output snapshot (one that was produced by
the update). We will follow up on tha
dy be a huge step
> forward.
>
> -Jack
>
>
> On Tue, May 28, 2024 at 1:40 PM Benny Chow wrote:
>
>> It's interesting to note that a tabular SQL UDF can be used to build a
>> *parameterized
>> *view. So, there's definitely a lot in common between UD
I think there is a disconnect about what is perceived as a "UDF". There are
2 flavors:
(1) Functions that are defined by the user whose definition is a
composition of other built-in functions/SQL expressions.
(2) Custom code written in imperative function according to a
Java/Scala/Python API, etc.
t;
> Also, Jan brought up interesting use case with BI tool using the MV
> without SQL representation. The BI tool can get all table and view
> dependencies if the lineage is complete.
>
> Thanks
>
>
> On May 17, 2024, at 1:35 PM, Walaa Eldin Moustafa
> wrote:
>
>
;> and Dataframe libraries. This is also how Trino is doing it. That's why we
>> chose the design in the google doc.
>>
>> Storing the storage table identifier as a property might work.
>>
>> Thanks, Jan
>> On 15.05.24 02:38, Walaa Eldin Moustafa wrote:
>
wonder what are your
> thoughts here Walaa?
>
> Thanks
>
> On May 14, 2024, at 4:20 PM, Walaa Eldin Moustafa
> wrote:
>
>
> Thanks John. The current metadata does not sound complex. We need to track
> the underlying table snapshot IDs as well as the view version
are quicker to adopt API changes
>(than engines), e.g., using Iceberg library to manipulate MVs, or parsing
>metadata files directly
>- Spark view catalog API can evolve separately from Iceberg API and
>spec changes
>
>
> Thanks all for the great discussion!
>
> field on the Storage Table's snapshot metadata. This allows you to 'time
> travel', 'branch', and have this metadata life cycle integrated via normal
> snapshots lifecycle operations.
>
> So that's my rationale. Not sure if we can come to an agr
complexity over new key/value properties?
> To me, the vote seemed to just rule out using a combined catalog object
> (MaterializedView) in favor of re-using the Table and View metadata models,
> not to prevent change to the Table and View model.
>
> Thanks
> Szehon
>
>
> On
t Spec in the design doc. What do people think?
>
> Thanks
> Szehon
>
>
>
> On Thu, May 9, 2024 at 5:35 PM Walaa Eldin Moustafa
> wrote:
>
>> Thanks Szehon.
>>
>> The reason for the difference is that the proposal in the Google doc is
>> based on a
start with a completely
>> different design because we are bound to have the same discussions all over
>> again.
>>
>> Thanks, Jan
>> On 08.05.24 12:11, Walaa Eldin Moustafa wrote:
>>
>> The only consensus the community had was on the object model through the
ached consensus which
> took a considerable amount of time.
>
> Thanks, Jan
> On 08.05.24 10:21, Walaa Eldin Moustafa wrote:
>
> Thanks Jan. I think we moved on to more alignment steps beyond that doc a
> while ago. After that doc, we have discussed the topic further in 2 de
ce the draft is finalized we can adopt the PR to reflect the consensus
> from the google doc.
>
> Best wishes,
>
> Jan
> On 07.05.24 19:11, Walaa Eldin Moustafa wrote:
>
> Thanks Steven. I feel it is needed so the MV spec is not scattered across
> the table and view spec pa
can be said about the storage table metadata.
>
> We may keep the separate materialized view page to document motivation,
> freshness semantics, etc..
>
> On Mon, May 6, 2024 at 10:58 PM Walaa Eldin Moustafa <
> wa.moust...@gmail.com> wrote:
>
>> Hi Everyone,
>>
>
Hi Everyone,
Thanks again for participating in the modeling discussion [1]. Since the
outcome of this discussion was to model materialized views as separate
objects, an Iceberg view and a table, I think the next step should be
discussing the metadata details for each object. I have created a PR
ht
gt; > On Apr 25, 2024, at 2:08 PM, Jean-Baptiste Onofré
>> wrote:
>> >
>> > +1 to separate, it makes sense to me.
>> >
>> > Regards
>> > JB
>> >
>> > On Thu, Apr 18, 2024 at 11:50 AM Walaa Eldin Moustafa
>> > wrote:
&g
;> +1 for this proposal.
>>>>>
>>>>> On Fri, Apr 19, 2024 at 3:40 PM Ajantha Bhat
>>>>> wrote:
>>>>>
>>>>>> +1 for the proposal.
>>>>>>
>>>>>> - Ajantha
>>>>>&
Hi everyone,
I would like to make a proposal for issue [1] to support materialized views
in Iceberg. The support leverages two separate objects, an Iceberg view and
an Iceberg table to implement materialized views. Each object retains
relevant metadata to support the MV operations. An initial desi
;> available).
>> >> >
>> >> > The vote is a confirmation of the direction, not a way to settle
>> disagreements about approaches.
>> >> >
>> >> > I think we need to have a more focused discussion (this can either
>> be at
e can schedule a time).
>> >
>> > -Dan
>> >
>> >
>> >
>> > On Mon, Apr 1, 2024 at 10:45 PM Jean-Baptiste Onofré
>> wrote:
>> >>
>> >> Hi Walaa
>> >>
>> >> Yes, I think it makes sense
te:
>
>> Hi Walaa
>>
>> Yes, I think it makes sense to go with a vote, now that pros/cons are
>> clearly state in the doc.
>>
>> Thanks !
>> Regards
>> JB
>>
>> On Tue, Apr 2, 2024 at 3:59 AM Walaa Eldin Moustafa
>> wrote:
>
know if I can help on that.
> >>
> >> I'm working on a PR to list the proposals on the website and the
> >> "stale reminder".
> >>
> >> Thanks !
> >> Regards
> >> JB
> >>
> >> On Thu, Mar 28, 2024 at 6:52 AM
1 - 100 of 149 matches
Mail list logo
