If there are no further notes, I'll go ahead and start the voting thread
today.
Thanks,
Leah
On Thu, May 20, 2021 at 2:58 PM Leah Thomas wrote:
> Thanks for finding that, Guozhang. Consistency seems like the best option
> to me as well, for the time being. I updated the KIP with that detail
>
Thanks for finding that, Guozhang. Consistency seems like the best option
to me as well, for the time being. I updated the KIP with that detail
On Thu, May 20, 2021 at 11:53 AM Sophie Blee-Goldman
wrote:
> Thanks Guozhang, I forgot about ConfigException. I actually just reviewed
> two KIPs rela
Thanks Guozhang, I forgot about ConfigException. I actually just reviewed
two KIPs related to config-based Serdes,
both of which use the ConfigException in this way: the ListSerde KIP, and
the KIP to clean up the windowed inner class
serde configuration.
For the sake of simplicity and keeping this
Hi,
I think using ConfigException makes sense. But I am also fine with
SerdeConfigurationException. I think both are meaningful in this
situation where the former has the advantage that we do not need to
introduce a new exception.
Best,
Bruno
On 20.05.21 07:54, Guozhang Wang wrote:
Than
Thanks Sophie. I think not piggy-backing on TopologyException makes sense.
It just occurs to me that today we already have similar situations even
with this config default to Bytes, that is the other
`DEFAULT_WINDOWED_KEY/VALUE_SERDE_INNER_CLASS` config, whose default is
actually null. Quickly che
To be honest I'm not really a fan of reusing the TopologyException since it
feels like
a bit of a stretch from a user point of view to classify Serde
misconfiguration as a
topology issue.
I personally think a StreamsException would be acceptable, but I would also
propose
to introduce a new type of
Leah, thanks for the KIP.
It looks good to me overall, just following up on @br...@confluent.io
's question about exception: what about using the
`TopologyException` class? I know that currently it is only thrown during
the topology parsing phase, not at the streams construction, but I feel we
ca
Hi Sophie,
Thanks for catching that. These are existing methods inside of
`StreamsConfig` that will return null (the new default) instead of byte
array serde (the old default). Both `StreamsConfig` and
`defaultKeySerde`/`defaultValueSerde` are public, so I assume these still
count as part of the p
Hey Leah,
> what I think should be a small discussion
Dangerous words, indeed! It seems like they trigger something in people ;-)
Jokes apart!
Did you consider throwing a more specific exception instead of a
StreamsException? Something that describes better the issue at hand.
Best,
Bruno
>
> what I think should be a small discussion
Dangerous words :P
I'm all for the proposal but I do have one question about something in the
KIP. You list two methods called
defaultKeySerde() and defaultValueSerde() but it's not clear to me where
these are coming from. Are they
new APIs you propo
10 matches
Mail list logo
