Thanks Waala for sharing the design document and the discussion. Few suggestions and points to consider
*First* : *How does it lay on the underlying Storage (HDFS/S3/ ...)* As I understood, option 1 is preferred from an implementation perspective and also some engines require a semantic storage table and view to define a MV. From a user's perspective, the user has asked to create one MV object and that would result in two different folder structures in HDFS or S3. How is the relation between View and Storage exposed to the user? I was wondering whether there is an option, where there is only one folder structure (data and metadata folders) holding everything needed for a MV, inside that storage table and view metadata can be separate. I think it sounds like option 2, but only from the point of view of how it lays on underlying storage. *Second*: *Alter MV and Schema Evolution* Typically alter table commands can modify datatype, add new columns, both of these cases would typically mean a refresh of the storage table, but the user may be fine, letting the storage table refresh based on the already setup cadence. In that case, should there be an option to provide default value for the newly added columns. Something like the below > `alter mv mv_name add column new_column string default "BLANK"` *Third: Exposing staleness states to view and visible in catalog* Many times a MV may contain a query with multiple source tables involved. In this design it is proposed that the storage table will have lineage record and that will contain source table details to determine staleness. How are users going to be exposed to this information? Should the view also have a property showing the staleness state of each table in the lineageRecord and then the user can decide whether to refresh before consuming. Apologies if this is not the right way to communicate these thoughts. Regards, Himadri Pal
