You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by GitBox <gi...@apache.org> on 2019/11/09 22:09:44 UTC

[GitHub] [flink] sjwiesman opened a new pull request #10142: Spa window reader

sjwiesman opened a new pull request #10142: Spa window reader
URL: https://github.com/apache/flink/pull/10142
 
 
   ## What is the purpose of the change
   
   Provide an easy way to read / bootstrap window state using the State Processor API.
   
   ## Brief changelog
   
   e5dcf6f Adds support for listing namespaces for a state type from `KeyedStateBackend`. This is required as windows are encoded as namespaces in the state backend and up until now there has never been a way to query namespaces, all operations assume the calling code already knows what namespace they are interested in interacting with.
   
   06919b7  Refactors the `KeyedStateInputFormat` to support arbitrary user function types. It now follows the model of Task -> Operator -> Function where the input format is the task, `StateReaderOperator` is the low-level operator that can be implemented for any function type. In the future this allows us to support reading other low-level encodings such as stateful functions. 
   
   5b13421 Adds support for reading window operator state by implementing a `WindowStateReaderOperator` and `WindowReaderFunction`. 
   
   1dee574 Extracts the logic from `WindowedStream` into a builder class so that there is one definitive way to create and configure the window operator. I ran all the end to end tests to ensure everything works as expected.
   
   361a225  Cursory refactoring of some test utilities
   
   557ad0d  Adds support for bootstrapping window state. While this commit contains a lot of code it is all boilerplate due to the many ways users can configure the window operator. All user-facing changes simply sit on top of the `WindowOperatorBuilder`. 
   
   ## Verifying this change
   
   Unit and IT tests cases
   
   ## Does this pull request potentially affect one of the following parts:
   
     - Dependencies (does it add or upgrade a dependency): no
     - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: no
     - The serializers: no
     - The runtime per-record code paths (performance sensitive): no
     - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
     - The S3 file system connector: no
   
   ## Documentation
   
     - Does this pull request introduce a new feature? yes
     - If yes, how is the feature documented? JavaDoc
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services