namest504 commented on PR #24842:
URL: https://github.com/apache/pulsar/pull/24842#issuecomment-3408924943
@lhotari
Thank you for the continued guidance. I want to confirm my understanding and
share my thoughts before proceeding with the implementation.
My understanding is that the goal here is to provide maximum
flexibility—evolving beyond a binary choice of payload vs raw message and
instead empowering users to transform a Message<T> into any custom object V
that fits their specific needs. Is this correct?
I agree this is a very appropriate and powerful extension for this feature.
For example
```java
public class OriginalData {
String a;
double b;
}
public class Foo {
String a;
double b;
long eventMetaA; // from message.getEventTime()
String eventMetaB; // from message.getProperty()
}
TableView<Foo> view = builder
.createMapped(message -> {
OriginalData original = message.getValue();
return new Foo(
original.a,
original.b,
message.getEventMetaA(),
message.getEventMetaB()
);
});
```
---
I do have two main concerns regarding potential edge cases, and I would
appreciate your guidance on them.
1. If a mapper function returns null: What would be the most appropriate way
for the TableView to handle this?
2. If the mapper throws an exception: What is the desired behavior in this
scenario?
Are these concerns that I should address in the implementation, or are they
handled by other parts of the system and not something I need to consider?
---
If my understanding of the direction is correct, I'd like to update the PIP
document and the implementation PR accordingly. Please let me know if this is
the right way to proceed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
