Type Members

1.  trait ProcessingTypeDataProvider[+Data, +CombinedData] extends AnyRef

   ProcessingType is a context of application.

   ProcessingType is a context of application. One ProcessingType can't see data from another ProcessingType. Services run inside one ProcessingType scope behave differently from services run in another scope.

   This class is meant to provide access to some scope of data inside context of application to the user. We don't want to pass all ProcessingType's data to every service because it would complicate testing of services and would broke isolation between areas of application. Due to that, this class is a Functor (to be precise BiFunctor but more on that below) which allows to transform the scope of Data.

   Sometimes it is necessary to have access also to combination of data across all ProcessingTypes. Due to that this class is a BiFunctor which second value named as CombinedData

   This class caches Data and CombinedData wrapped in ProcessingTypeDataState to avoid computations of transformations during each lookup to Data/CombinedData. It behave similar to Observable where given transformed ProcessingTypeDataProvider check its parent if ProcessingTypeDataState.stateIdentity changed.

   ProcessingType is associated with Category e.g. Fraud Detection, Marketing. Given user has access to certain categories see LoggedUser.can. Due to that, during each access to Data, user is authorized if he/she has access to category.

2.  trait ProcessingTypeDataState[+Data, +CombinedData] extends AnyRef
3.  class ReloadableProcessingTypeDataProvider extends ProcessingTypeDataProvider[ProcessingTypeData, CombinedProcessingTypeData] with LazyLogging

   This implements *simplistic* reloading of ProcessingTypeData - treat it as experimental/working PoC

   This implements *simplistic* reloading of ProcessingTypeData - treat it as experimental/working PoC

   One of the biggest issues is that it can break current operations - when reloadAll is invoked, e.g. during process deploy via FlinkRestManager it may very well happen that http backed is closed between two Flink invocations. To handle this correctly we probably need sth like: def withProcessingTypeData(processingType: ProcessingType)(action: ProcessingTypeData=>Future[T]): Future[T] to be able to wait for all operations to complete

   Another thing that needs careful consideration is handling exception during ProcessingTypeData creation/closing - probably during close we want to catch exception and try to proceed, but during creation it can be a bit tricky...