merlimat commented on a change in pull request #3904: [go schema] support go
schema for pulsar-client-go
URL: https://github.com/apache/pulsar/pull/3904#discussion_r276216671
##########
File path: pulsar-client-go/pulsar/client.go
##########
@@ -101,17 +101,17 @@ type ClientOptions struct {
type Client interface {
// Create the producer instance
// This method will block until the producer is created successfully
- CreateProducer(ProducerOptions) (Producer, error)
+ CreateProducer(ProducerOptions, Schema) (Producer, error)
Review comment:
It's not a super-important thing.
I, of course, completely agree on maintaining the same concepts across
languages APIS. That's why I was insisting in having the same concept of schema
as in Java/Python.
When we drill down to the lower level though, there are already differences
in the ergonomics of the API between Java and Go, and for a good reasons: to
maintain a "native" feeling for the API.
In general, we've been following the path of simplification for Go API (as
simpler APIs are generally preferred there) and, in this specific context, I'd
rather avoid duplicating the methods (create with schema and create without
schema).
`ProducerOption` is really the equivalent of the builder or the args for
Python. For example, in python we're doing:
```python
producer = client.create_producer(
topic='my-topic',
schema=AvroSchema(Example) )
```
which would be the equivalent of
```go
producer, err := client.CreateProducer(pulsar.ProducerOptions{
Topic: "my-topic",
Schema: NewAvroSchema(...),
})
```
So I don't know whether `ProducerOptions` is already poorly named or what's
the line between configuration and functionality.
To me, it seems more natural to have a single structure to "declare" how the
producer look like.
Having said that, I can live with both approaches.
----------------------------------------------------------------
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:
us...@infra.apache.org
With regards,
Apache Git Services
