Hi Jiunn-Yang, Thanks for the updates!
IMO, "allow.null.entries" might be a little too vague. Is "allow.null.offsets.entries" better? Thanks, Kirk On Tue, Apr 22, 2025, at 6:03 AM, 黃竣陽 wrote: > Hello everyone, > > I’ve submitted an updated version of this KIP based on recent discussions. > I'm happy to hear any further concerns > or suggestions you might have. > > <https://cwiki.apache.org/confluence/x/mIuMEw> > > Best Regards, > Jiunn-Yang > > > 黃竣陽 <s7133...@gmail.com> 於 2025年4月22日 下午6:35 寫道： > > > > Hello, > > > > Thank for the feedback. I will address this new/deprecated mechanism in the > > updated version of the KIP. > > > > Best Regards, > > Jiunn-Yang > > > >> Chia-Ping Tsai <chia7...@gmail.com> 於 2025年4月22日 中午12:58 寫道： > >> > >> hi Matthias > >> > >> Thanks for offering this approach. I had considered proposing it before. > >> My concern was the new/deprecated config is used by client, so it could > >> cause a bunch of warning messages by default. Also, users have to add the > >> new/deprecated config to each client properties if they want to eliminate > >> the noise. > >> > >> However, as Juma mentioned that the approach was applied by another KIP > >> before, so +1 to the new/deprecated config. > >> > >> To Ken > >> > >> Could you please update the KIP to include the new config? Additionally, > >> please add the other discussed approaches to the “rejected” section. > >> > >> Best, > >> Chia-Ping > >> > >> > >> > >> > >>> Ismael Juma <m...@ismaeljuma.com.invalid> 於 2025年4月22日 上午11:03 寫道： > >>> > >>> That's right. Similar approach: > >>> https://lists.apache.org/thread/3fxqdsosm3z7xp4rr8db2qmyg5vd0v1b > >>> > >>> Ismael > >>> > >>>> On Mon, Apr 21, 2025, 7:43 PM Matthias J. Sax <mj...@apache.org> wrote: > >>>> > >>>> I don't think we would need a second deprecation cycle. > >>>> > >>>> Instead, we could add this new config, and deprecate it right away. This > >>>> way, we can change the default behavior and remove the config both with > >>>> 5.0. > >>>> > >>>> I guess the core question is really, do we want to enable the old or new > >>>> behavior by default? From a backward compatibility POV, we would need to > >>>> keep the old behavior as default IMHO. > >>>> > >>>> If we can agree to this, the way forward might be: > >>>> > >>>> - keep the old behavior as default > >>>> - add a config that allows to enable the new behavior > >>>> - if use don't enable the new behavior, log a WARN telling them that > >>>> they need to migrate their code before 5.0 and encourage them to enable > >>>> the new behavior right away > >>>> - deprecate the new config right away > >>>> - remove the config and old behavior in 5.0 > >>>> > >>>> > >>>> I admit, that adding a new config, and deprecating it, plus telling > >>>> users "please use this new/deprecated config", is a little bit awkward > >>>> -- but it seems to be still the overall best way forward IMHO? > >>>> > >>>> > >>>> > >>>> -Matthias > >>>> > >>>>> On 4/17/25 8:16 PM, Chia-Ping Tsai wrote: > >>>>> hi Kirk > >>>>> > >>>>> “coarsely grained” is a good point. We need to list all behaviors > >>>> impacted by the config - no matter which new config we adopted. > >>>>> > >>>>> Maybe we can add the flag to xxxOption? The benefit is users can > >>>> explicitly see “which” APIs are impacted. The downside is the number of > >>>> deprecated methods in 5.0 is increased > >>>>> > >>>>> Best, > >>>>> Chia-Ping > >>>>> > >>>>>> Kirk True <k...@kirktrue.pro> 於 2025年4月18日 清晨7:16 寫道： > >>>>>> > >>>>>> Hi Colin, > >>>>>> > >>>>>> If so, is 5.0 the earliest this 'allow.nulls.in.consumer' configuration > >>>> can be changed and marked as deprecated? And if that holds, is 6.0 the > >>>> earliest it can be removed? > >>>>>> > >>>>>> Thanks, > >>>>>> Kirk > >>>>>> > >>>>>>> On Mon, Apr 14, 2025, at 1:10 PM, Colin McCabe wrote: > >>>>>>> I would suggest adding a configuration key which controls whether the > >>>> null values are added. That configuration key can default to true in 4.x > >>>> and false in 5.x. This will give people a chance to test the new behavior > >>>> before 5.x. > >>>>>>> best, > >>>>>>> Colin > >>>>>>>> On Fri, Mar 14, 2025, at 04:30, 黃竣陽 wrote: > >>>>>>>> Hello everyone, > >>>>>>>> I would like to start a discussion on KIP-1140: Avoid to return null > >>>>>>>> value in Map from public api of consumer > >>>>>>>> <https://cwiki.apache.org/confluence/x/mIuMEw> > >>>>>>>> This proposal aims to improve the Kafka consumer API by ensuring that > >>>>>>>> the Map it returns contains only non-null values, > >>>>>>>> aligning with the design philosophy of Java collections. This change > >>>>>>>> provides significantly more benefits than drawbacks, > >>>>>>>> enhancing API consistency and usability while reducing errors caused > >>>> by > >>>>>>>> developer misuse. > >>>>>>>> Best Regards, > >>>>>>>> Jiunn-Yang > >>>> > >>>> > > > >
