In short, this change is okay for me. But since it's a breaking
change, the Pulsar PMCs should be responsible to make the idea pass.
Thanks,
Yunze
On Fri, Dec 16, 2022 at 11:53 AM Yunze Xu wrote:
>
> PIP is required when you want to make a breaking change. [1] What you
> think is wrong might hav
PIP is required when you want to make a breaking change. [1] What you
think is wrong might have been applied in existing applications, just
like the comments here [2]
The only controversial point is that should we treat it as a breaking
change? From [3]
> A change in one part of a software system
It doesn’t matter if PIP is open. can directly describe it clearly in
https://lists.apache.org/thread/mbrpjsgrgwrlkdpvkk738jxnlk7rf4qk and
modify it. But either newly opened PIP or in
https://lists.apache.org/thread/mbrpjsgrgwrlkdpvkk738jxnlk7rf4q, my
point is that we need to fix it, not compatible
Let's see another example that is considered as a "bug", not a breaking change.
https://lists.apache.org/thread/88t1xxf68j092k09srdwyzj1tk4ml5n9
> I think that this is fixing a bug, if the topic does not exist we should
> return "not found".
The "bug" and "breaking change" are not in contrast.
I still feel better to change compareTo directly.
1. Although using PulsarApiMessageId.campare() can reduce the
probability of developers using errors, it cannot be completely
avoided.
2. While a direct change would change the default behavior, I consider
it a bug, not a breaking change. We can e
Actually I'm refactoring the MessageId related code [1], whose current
implementations are very messy from my perspective. My solution to
this issue is adding two compare methods, one of them is the "wrong"
implementation and used in `MessageId#compareTo` to avoid the breaking
change. See the `lega
Hi, Yunze:
If we don't change this behavior, we should pay special attention when
coding `pulsar-client`, because it is a point that is easy to
overlook. its impact may be more serious than "wrong " behavior
produced by the user using the current compareTo() method manually. I
don’t think this is a
Actually, from the user side, this comparison would never happen.
Users could never receive two MessageId objects with the same ledger
id, entry id while the batch index fields are different. This
comparison could only exist in the `pulsar-client` implementation.
If users touch the case, the Messa
Hi, all:
does anyone have any suggestions?
Thanks,
bo
丛搏 于2022年11月21日周一 18:57写道：
>
> Hello, Pulsar community:
>
> now when `BatchMessageIdImpl` and `MessageIdImpl` with the same
> `ledgerId` and `EntryId`, one of it compare with the other, the
> `BatchMessageIdImpl` will always be greater than
Hello, Pulsar community:
now when `BatchMessageIdImpl` and `MessageIdImpl` with the same
`ledgerId` and `EntryId`, one of it compare with the other, the
`BatchMessageIdImpl` will always be greater than MessageIdImpl.
see :
https://github.com/apache/pulsar/blob/master/pulsar-client/src/main/java/o
10 matches
Mail list logo
