You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2021/06/07 20:00:53 UTC

[GitHub] [pulsar] nlu90 commented on pull request #10631: [Functions] reorganize the context hierarchy for functions

nlu90 commented on pull request #10631:
URL: https://github.com/apache/pulsar/pull/10631#issuecomment-856215827


   > While I am ok with doing some refactoring in the interfaces we have for Source, Sink, and Function context, this PR also exposes interfaces that are originally only for FunctionContext to SourceContext and SinkContext. We should consider carefully before introducing these new interfaces in Source and Sink Context. I don't want to expose functionality that is not needed.
   > 
   > If this is just a refactor, please keep the current interfaces exposed for FunctionContext, SourceContext, and SinkContext.
   
   @jerrypeng Thanks for the review.  Despite the previous shared interfaces, the followings new interfaces are exposed to connectors:
   
   ```
   default <S extends StateStore> S getStateStore(String name) {
           throw new UnsupportedOperationException("Component cannot get state store");
       }
   
   default PulsarAdmin getPulsarAdmin() {
           throw new UnsupportedOperationException("Component cannot access pulsar admin");
       }
       
   default PulsarAdmin getPulsarAdmin(String clusterName) {
           throw new UnsupportedOperationException("Component cannot access pulsar admin");
       }
   
   default <O> CompletableFuture<Void> publish(String topicName, O object, String schemaOrSerdeClassName) {
           throw new UnsupportedOperationException("Component cannot publish message");
       }
   
   default <O> CompletableFuture<Void> publish(String topicName, O object) {
           throw new UnsupportedOperationException("Component cannot publish message");
       }
   
   default <O> TypedMessageBuilder<O> newOutputMessage(String clusterName, String topicName, Schema<O> schema)
               throws PulsarClientException {
           throw new UnsupportedOperationException("Component can not output message to pulsar cluster");
       }
       
   default <O> TypedMessageBuilder<O> newOutputMessage(String topicName, Schema<O> schema)
               throws PulsarClientException {
           throw new UnsupportedOperationException("Component can not output message to pulsar cluster");
       }
   
   default <O> ConsumerBuilder<O> newConsumerBuilder(Schema<O> schema) throws PulsarClientException {
           throw new UnsupportedOperationException("Component can not create consumer builder");
       }
   ```
   
   Based on my understanding, these are pulsar cluster interaction methods that connectors may need. And actually, I'm planning to add one more interface `getPulsarClient` as a following PR to fix https://github.com/apache/pulsar/pull/8668 more concretely. 
   
   But I might be missing some of the context here, so please let me know which of the newly exposed functionality is not needed and we can discuss and update accordingly.


-- 
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