BartMiki commented on issue #12912:
URL: https://github.com/apache/druid/issues/12912#issuecomment-1221270674
@FrankChen021 Regarding the changes to the Event I wonder if that is the
best approach. My take is that `ACustomerMap` shouldn't be responsible for
serialization. If we want to support more formats (le'ts say Avro, XML,
Protobuf etc) then we need to extend this `ACustomerMap`. Maybe something like
this?
```java
public abstract class EventSerializer<T> {
public T serialize(Event event) {
return serialize(event, Collections.emptyMap());
}
public abstract T serialize(Event event, Map<String, Object>
additionalProperties);
}
```
And then we can have for example:
```
public class EventToJsonStringSerializer implements EventSerializer<String>
{ ... }
public class EventToXMLStringSerializer implements EventSerializer<String> {
... }
public class EventToObjectNodeSerializer implements
EventSerializer<ObjectNode> { ... }
public class EventToByteArraySerializer implements Event<byte[]> {...}
```
So the users can use the provided serializers and the serializers can use
the `toMap` or whatever else regarding the event. The upshot is that we have
unified interface for serializing events to anything and the implementation
always is in a single class. The downside is the change affects all emitters.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
