If selection exists in header, the selection should override the config value. Cheers -------- Original message --------From: Luis Cabral <luis_cab...@yahoo.com.INVALID> Date: 6/15/18 1:40 AM (GMT-08:00) To: dev@kafka.apache.org Subject: Re: [VOTE] KIP-280: Enhanced log compaction Hi,
bq. Can the value be determined now ? My thinking is that what if there is a third compaction strategy proposed in the future ? We should guard against user unknowingly choosing the 'future' strategy. The idea is that the header name to use is flexible, which protects current clients that may want to use this from having to adapt their already existing header names (they can just specify a new name). bq. Shouldn't the selection in header have higher precedence over the configuration ? Not sure what you mean here, could you clarify? bq. Please create JIRA if you haven't already. Done: https://issues.apache.org/jira/browse/KAFKA-7061 Cheers, Luís > On 11 Jun 2018, at 01:50, Ted Yu <yuzhih...@gmail.com> wrote: > > bq. When this configuration is set to anything other than "*offset*" or " > *timestamp*", then the record headers are scanned for a key matching this > value. > > Can the value be determined now ? My thinking is that what if there is a > third compaction strategy proposed in the future ? We should guard against > user unknowingly choosing the 'future' strategy. > > bq. If this header is found > > Shouldn't the selection in header have higher precedence over the > configuration > ? > > Please create JIRA if you haven't already. > > Thanks > > On Sat, Jun 9, 2018 at 12:39 AM, Luís Cabral <luis_cab...@yahoo.com.invalid> > wrote: > >> Hi all, >> >> Any takers on having a look at this KIP and voting on it? >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP- >> 280%3A+Enhanced+log+compaction >> >> Cheers, >> Luis >>
