Here is a summary of yesterday's community sync-up.
Yufei gave a brief update on disaster recovery requirements and the current progress of relative path approach. Ryan: We all agreed that relative path is the way for disaster recovery. *Multiple roots for the relative path* Ryan proposed an idea to enable multiple roots for a table, basically, we can add a list of roots in table metadata, and use a selector to choose different roots when we move the table from one place to another. The selector reads a property to decide which root to use. The property could be either from catalog or the table metadata, which is yet to be decided. Here is an example I’d image: 1. Root1: hdfs://nn:8020/path/to/the/table 2. Root2: s3://bucket1/path/to/the/table 3. Root3: s3://bucket2/path/to/the/table *Relative path use case* We brainstormed use cases for relative paths. Please let us know if there are any other use cases. 1. Disaster Recovery 2. Jack: AWS s3 bucket alias 3. Ryan: fall-back use case. In case that the root1 doesn’t work, the table falls back to root2, then root3. As Russell mentioned, it is challenging to do snapshot expiration and other table maintenance actions. *Timeline* In terms of timeline, relative path could be a feature in Spec V3, since Spec V1 and V2 assume absolute path in metadata. *Misc* 1. Miao: How is the relative path compatible with the absolute path? 2. How do we migrate an existing table? Build a tool for that. Please let us know if you have any ideas, questions, or concerns. Yufei
