The cut-off line for the builder was to just port whatever is currently in
connect so that we don't break the APIs there. Perhaps it's better to just
introduce the critical methods (partitions/replicas/configs) and have the
one in connect just extend the new one.
On Fri, May 10, 2019 at 3:24 AM Ma
I minor comment about `.compacted()` method:
It might be better to change to `cleanupPolicy(CleanupPolicy)` and add
an enum `CleanupPolicy` with fields `DELETE`, `COMPACT`, `DELETE_COMPACT`.
Also, for the cleanup policy, what about retention time vs size?
I am also wondering, what the cut-off li
Moving discussion on VOTE thread here:
Ismael asked:
> Adding a Builder seems unrelated to this change. Do we need it? Given the
> imminent KIP deadline, I'd keep it simple and just have the constructor
> with just the name parameter.
If we want the flexibility that the builder provides we would
I personally like those extra methods, rather than relying upon the generic
properties. But I'm fine if others think they should be removed. I'm also
fine with not deprecating the Connect version of the builder.
On Fri, May 3, 2019 at 11:27 AM Almog Gavra wrote:
> Ack. KIP updated :) Perhaps ins
Ack. KIP updated :) Perhaps instead of deprecating the Connect builder,
then, we can indeed just subclass it and move some of the less common build
methods (e.g. uncleanLeaderElection) there.
On Fri, May 3, 2019 at 11:20 AM Randall Hauch wrote:
> Thanks for updating, Almog. I have a few suggesti
Thanks for updating, Almog. I have a few suggestions specific to the
builder:
1. The AK pattern for builder classes that are nested is to name the class
"Builder" and to make it publicly visible. We should follow that pattern
here, too.
2. The builder's private constructor makes it impossible to s
Thanks for the input Randall. I'm happy adding it natively to NewTopic
instead of introducing more verbosity - updating the KIP to reflect this
now.
On Thu, May 2, 2019 at 9:28 AM Randall Hauch wrote:
> I wrote the `NewTopicBuilder` in Connect, and it was simply a convenience
> to more easily se
I wrote the `NewTopicBuilder` in Connect, and it was simply a convenience
to more easily set some of the frequently-used properties and the # of
partitions and replicas for the new topic in the same way. An example is:
NewTopic topicDescription = TopicAdmin.defineTopic(topic).
Sure thing, added more detail to the KIP! To clarify, the plan is to move
an existing API from one package to another (NewTopicBuilder exists in the
connect.runtime package) leaving the old in place for compatibility and
deprecating it.
I'm happy to hear thoughts on whether we should (a) move it t
If you are adding new API, you need to specify it all in the KIP.
Ismael
On Thu, May 2, 2019, 8:04 AM Almog Gavra wrote:
> I think that sounds reasonable - I updated the KIP and I will remove the
> constructor that takes in only partitions.
>
> On Thu, May 2, 2019 at 4:44 AM Andy Coates wrote:
I think that sounds reasonable - I updated the KIP and I will remove the
constructor that takes in only partitions.
On Thu, May 2, 2019 at 4:44 AM Andy Coates wrote:
> Rather than adding overloaded constructors, which can lead to API bloat,
> how about using a builder pattern?
>
> I see it’s alr
Rather than adding overloaded constructors, which can lead to API bloat, how
about using a builder pattern?
I see it’s already got some constructor overloading, but we could add a single
new constructor that takes just the name, and support everything else being set
via builder methods.
This w
"lack of default doesn't force people to think - it gets them to pick a
random number" - I suppose if I'm being pragmatic this rings very true to
my experience as well... better a cluster administrator sets a sane default
than having users choose random numbers!
Consider me convinced - I'll update
Changing number of partitions is complicated in some use-cases and easy in
other cases (when you use Kafka as a big pipe of events on the way to
another system).
I like making easy things easy and complex things complicated. Having
defaults for both will allow the easy cases to be even easier.
In
I have a preference toward requiring specifying partitions per topic, but
I'm happy to be convinced otherwise. Changing replication factor after the
fact is easy, but changing partitions is complicated since historical state
gets messed up, so it could be beneficial to force clients to think about
Thanks for the KIP, Almog. This is a good change. I think we should also
allow the partition count broker default to be used (the one used for auto
topic creation).
Ismael
On Tue, Apr 30, 2019, 8:39 AM Almog Gavra wrote:
> Hello Everyone,
>
> I'd like to start a discussion on KIP-464:
>
> https
16 matches
Mail list logo
