Hello Matthias, Just to clarify the naming conflicts is between the newly added function and the old functions that we want to deprecate / remove right? The existing ones have different signatures with parameters so that they should not have conflicts.
I was thinking about just make the change directly without deprecating existing ones which would require users of 2.3 to make code changes -- this code change looks reasonably straight-forward to me and not much worth deferring to later when the deprecated ones are removed. On the other hand, just deprecating "WindowIterator" without add new functions seems not very useful for users either since it is only used as an indicator but users cannot make code changes during this phase anyways, so it is still a `one-cut` deal when we eventually remove the deprecated ones and add the new one. Hence I'm slightly inclining to trade compatibility and replace it with new functions in one release, but if people have a good idea of the renaming approach (I do not have a good one on top of my head :) I can also be convinced that way. Guozhang On Mon, Mar 11, 2019 at 10:41 AM Matthias J. Sax <matth...@confluent.io> wrote: > I am open to change the return type to > > KeyValueIterator<Windowed<K>, V> > > However, this requires to rename > > #fetch(K key, long startTimestamp, long endTimestamp) > #fetch(K key, Instant startTimestamp, Instant endTimestamp) > > to avoid naming conflicts. > > What new name would you suggest? The existing methods are called > `fetch()`, `fetchAll()`, `all()`, `put()`. > > While I think it would be good to get fully aligned return types, I am > not sure how we can get aligned method names (without renaming all of > them...)? If we think it's worth to rename all to get this cleaned up, I > am no opposed. > > > Thoughts? > > > -Matthias > > > On 3/11/19 10:27 AM, Guozhang Wang wrote: > > I was thinking about changing the return type even, to > > `KeyValueIterator<Windowed<K>, V>` since it is confusing to users about > the > > key typed `Long` (Streams javadoc today did not explain it clearly > either), > > note it is not backward compatible at all. > > > > Personally I'd prefer to just deprecate the API and new new ones that > > return `KeyValueIterator<Windowed<K>, V>` directly, but if most people > felt > > it is too intrusive for compatibility I can be convinced with > > `KeyValueIterator<Long, V>` as well. > > > > Guozhang > > > > On Mon, Mar 11, 2019 at 10:17 AM Sophie Blee-Goldman < > sop...@confluent.io> > > wrote: > > > >> I remember thinking this while working on window stores, am definitely > for > >> it. > >> > >> On Mon, Mar 11, 2019 at 9:20 AM John Roesler <j...@confluent.io> wrote: > >> > >>> Sounds great to me. Thanks, Matthias! > >>> -John > >>> > >>> On Sun, Mar 10, 2019 at 11:58 PM Matthias J. Sax < > matth...@confluent.io> > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> I would like to propose KIP-439 to deprecate interface > >>>> `WindowStoreIterator`. > >>>> > >>>> > >>>> > >>> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-439%3A+Deprecate+Interface+WindowStoreIterator > >>>> > >>>> Looking forward to your feedback. > >>>> > >>>> > >>>> -Matthias > >>>> > >>>> > >>> > >> > > > > > > -- -- Guozhang
