Github user uce commented on the pull request:
https://github.com/apache/flink/pull/2051#issuecomment-222625496
1. I think that you are very much looking at it with your specific use case
in mind, which is (I think) querying other operators from within your
operators. To me, that's not the main use case for queryable state though...
For that, it's true that the `QueryableStateStream` does not provide much help.
If you are already using partitioned state manually, then you will probably go
with the `setQueryable` method, that's true. But for some state like Flink's
internal windows, you don't have access to the `StateDescriptor` (which is
currently not exposed for queries on the API though). Furthermore, I think it's
good to provide a low barrier way of doing things. But if others feel the same,
I'm certainly OK with removing it.
2. I think that would be possible, yes. I agree that the
`QueryableStateStream` is conceptually similar to a sink.
3. I agree, but that was on purpose for the first version until we figure
out how to expose it properly. You have utilities in `KvStateRequestSerializer`
to serialize key and namespace and you can use `QueryableStateStream` to access
the key and value serializer. Namespace is usually `VoidNamespace` if you are
not querying windows.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
