Hi Leonard, Thanks for this FLIP! Looks good from my side.
Cheers, Fabian Am Do., 30. Juli 2020 um 22:15 Uhr schrieb Seth Wiesman <sjwies...@gmail.com >: > Hi Leondard, > > Thank you for pushing this, I think the updated syntax looks really good > and the semantics make sense to me. > > +1 > > Seth > > On Wed, Jul 29, 2020 at 11:36 AM Leonard Xu <xbjt...@gmail.com> wrote: > > > Hi, Konstantin > > > > > > > > 1) A "Versioned Temporal Table DDL on source" can only be joined on > the > > > PRIMARY KEY attribute, correct? > > Yes, the PRIMARY KEY would be join key. > > > > > > > > 2) Isn't it the time attribute in the ORDER BY clause of the VIEW > > definition that defines > > > whether a event-time or processing time temporal table join is used? > > > > I think event-time or processing-time temporal table join depends on fact > > table’s time attribute in temporal join rather than from temporal table > > side, the event-time or processing time in temporal table is just used to > > split the validity period of versioned snapshot of temporal table. The > > processing time attribute is not necessary for temporal table without > > version, only the primary key is required, the following VIEW is also > valid > > for temporal table without version. > > CREATE VIEW latest_rates AS > > SELECT currency, LAST_VALUE(rate) -- only keep the latest > > version > > FROM rates > > GROUP BY currency; -- inferred primary key > > > > > > > > > > 3) A "Versioned Temporal Table DDL on source" is always versioned on > > > operation_time regardless of the lookup table attribute (event-time or > > > processing time attribute), correct? > > > > > > Yes, the semantics of `FOR SYSTEM_TIME AS OF o.time` is using the o.time > > value to lookup the version of the temporal table. > > For fact table has the processing time attribute, it means only lookup > the > > latest version of temporal table and we can do some optimization in > > implementation like only keep the latest version. > > > > > > Best > > Leonard >
