Thanks Po-An for the heads up, I have just removed the deprecation plan in the KIP. That was discussed before. As we don't want to break the compatible to client, we shouldn't remove any existing API.
Best regards, Peter PoAn Yang <pay...@apache.org> 於 2025年3月27日 週四 下午5:55寫道： > Hi Chu Cheng Li, > > In KIP-1104, there is deprecation plan for old join methods. However, in > the PR #17756, > it didn't mark these functions as deprecated. Do we still want to > deprecate join methods? > Or we can remove deprecation plan in the KIP. Thanks! > > Best Regards, > PoAn > > On 2024/11/19 17:55:32 Chu Cheng Li wrote: > > Thanks guys ! > > BiFunction seems promising! > > > > KIP updated! > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1104%3A+Allow+Foreign+Key+Extraction+from+Both+Key+and+Value+in+KTable+Joins > > <https://bitli.pro/2i7Ja_1c6b6a68> > > > > On Wed, Nov 13, 2024 at 8:30 AM Matthias J. Sax <mj...@apache.org> > wrote: > > > > > I can just second was Lucas and Bill said already. > > > > > > 1. We cannot break compatibility > > > 2. BiFunction sounds like a good alternative > > > 3. I would personally deprecate the existing method, but don't feel > > > strong about it. > > > > > > > > > -Matthias > > > > > > > > > On 11/12/24 8:33 AM, Bill Bejeck wrote: > > > > Hi Peter, > > > > > > > > It's important that we don't break compatibility. > > > > We faced a similar situation in KIP-149 > > > > < > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-149%3A+Enabling+key+access+in+ValueTransformer%2C+ValueMapper%2C+and+ValueJoiner > > > > > > > > when we > > > > provided access to the key in mapping and joining. I think it's worth > > > > exploring Lucas's suggestion of using a `BiFunction`. > > > > But if for some reason it won't work (I don't see why it wouldn't) > we'll > > > > need to maintain compatibly and go with the renaming the new method. > > > > > > > > Thanks, > > > > Bill > > > > > > > > On Tue, Nov 12, 2024 at 8:06 AM Lucas Brutschy > > > > <lbruts...@confluent.io.invalid> wrote: > > > > > > > >> Hi, > > > >> > > > >> 1. I don't think we can/should break backwards compatibility. > > > >> 2. Have you considered using `BiFunction<K,V,KO> > foreignKeyExtractor` > > > >> ? This should work without renaming the method. > > > >> 3. I don't see the benefit of deprecating it. I agree, we wouldn't > add > > > >> both overloads normally, but the value-only overload is useful / > > > >> correct as it is, I wouldn't break users code just to "clean" things > > > >> very slighly. > > > >> > > > >> Cheers, > > > >> Lucas > > > >> > > > >> On Mon, Nov 11, 2024 at 6:43 PM Chu Cheng Li <peterx...@gmail.com> > > > wrote: > > > >>> > > > >>> Hi all, > > > >>> > > > >>> I'm working on enhancing the KTable foreign key join API to allow > > > >>> extracting foreign keys from both key and value. However, I've > > > >> encountered > > > >>> a Java type erasure issue that affects our API design choices. > > > >>> > > > >>> Current Situation: > > > >>> - We want to allow foreign key extraction from both key and value > > > >>> - We'd like to maintain backward compatibility with existing > value-only > > > >>> extractors > > > >>> - Initial attempt was to use method overloading > > > >>> > > > >>> The Issue: > > > >>> Due to Java type erasure, we can't have both: > > > >>> - Function<V, KO> foreignKeyExtractor > > > >>> - Function<KeyValue<K, V>, KO> foreignKeyExtractor > > > >>> in method overloads as they become identical at runtime. > > > >>> > > > >>> Options: > > > >>> 1. Breaking Change Approach > > > >>> - Replace value-only extractor with key-value extractor > > > >>> - Clean API but breaks backward compatibility > > > >>> > > > >>> 2. Compatibility Approach > > > >>> - Keep both capabilities through different method names (e.g., > > > >>> join/joinWithKey) > > > >>> - Maintains compatibility but less elegant API > > > >>> > > > >>> Questions for Discussion: > > > >>> 1. Should we prioritize API elegance or backward compatibility? > > > >>> 2. If we choose compatibility, which naming convention should we > use > > > for > > > >>> the new methods? > > > >>> 3. Should we consider deprecating the value-only extractor in a > future > > > >>> release? > > > >>> > > > >>> Looking forward to your thoughts. > > > >>> > > > >>> Best regards, > > > >>> Peter > > > >>> > > > >>> On Thu, Oct 31, 2024 at 1:08 PM Chu Cheng Li <peterx...@gmail.com> > > > >> wrote: > > > >>> > > > >>>> Hi Everyone, > > > >>>> I would like to start a discussion on KIP-1104: > > > >>>> > > > >>>> > > > >> > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1103%3A+Additional+metrics+for+cooperative+consumption > > > >>>> <https://bitli.pro/2h2om_f8e74a0c> > > > >>>> > > > >>>> This KIP allow foreign key extraction from both key and value in > > > KTable > > > >>>> Joins, before this KIP user can only extract foreign from record's > > > >> value, > > > >>>> this KIP provides more flexibility on it. > > > >>>> > > > >>>> Regards, > > > >>>> Peter Lee > > > >>>> > > > >>>> > > > >>>> > > > >> > > > > > > > > > >
