pnowojski commented on a change in pull request #7065: [FLINK-10626] [docs] [table] Add documentation for event-time temporal table joins URL: https://github.com/apache/flink/pull/7065#discussion_r232268635
########## File path: docs/dev/table/streaming/joins.md ########## @@ -189,14 +189,26 @@ val result = orders </div> </div> +**Note**: State retention defined in a [query configuration](query_configuration.html) is not yet considered for temporal joins. This means that the required state to compute the query result might grow infinitely depending on the number of distinct primary keys for the history table. + ### Processing-time Temporal Joins With a processing-time time attribute, it is impossible to pass _past_ time attributes as an argument to the temporal table function. -By definition, it is always the current timestamp. Thus, processing-time temporal table function invocations will always return the latest known versions of the underlying table +By definition, it is always the current timestamp. Thus, invocations of a processing-time temporal table function will always return the latest known versions of the underlying table and any updates in the underlying history table will also immediately overwrite the current values. Only the latest versions (with respect to the defined primary key) of the build side records are kept in the state. New updates will have no effect on the previously results emitted/processed records from the probe side. -One can think about processing-time temporal join as a simple `HashMap<K, V>` that stores all of the records from the build side. +One can think about a processing-time temporal join as a simple `HashMap<K, V>` that stores all of the records from the build side. When a new record from the build side has the same key as some previous record, the old value is just simply overwritten. Every record from the probe side is always evaluated against the most recent/current state of the `HashMap`. + +### Event-time Temporal Joins + +With an event-time time attribute (i.e., a rowtime attribute), it is possible to pass _past_ time attributes to the temporal table function. This allows for joining the two tables at a common point in time. + +Compared to processing-time temporal joins, the temporal table does not only keep the latest version (with respect to the defined primary key) of the build side records in the state but stores multiple versions of them identified by time. Review comment: `but stores multiple versions of them identified by time.` -> `but stores all of the versions since a last watermark`.? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
