RonBarabash commented on a change in pull request #131: Add the ability to
update event by item id
URL: https://github.com/apache/unomi/pull/131#discussion_r386860870
##########
File path: wab/src/main/java/org/apache/unomi/web/ServletCommon.java
##########
@@ -73,6 +73,9 @@ public static Changes handleEvents(List<Event> events,
Session session, Profile
logger.warn("Event is not allowed : {}",
event.getEventType());
continue;
}
+ if (event.getItemId() != null) {
Review comment:
Hey @sergehuber,
So the solution u suggested might work but it doesn't seem very scalable to
create a new event type for each entity, i think it would create a lot of mess
within the data, and how would you treat these events on the query side, if you
would want to create a rather complex aggregation which involves the update
events + the created events? i would say that it would be over-complicating
things for a rather simple & straight solution.
I think that if you would like to have full traceability of what happened
overtime u might want to save this somewhere else outside of Unomi, maybe fire
state changed events to Kafka and take it from there like
([CDC](https://en.wikipedia.org/wiki/Change_data_capture))
About our use case:
So we are now at the beginning of building Yotpo's internal CDP based on
apache Unomi.
As i mentioned earlier. we compose the user profiles based on internal
system events which are themselves state changed events of core Yotpo entities.
(i.e OrderCreated, ReviewCreated, PointsRedeemed etc)
All of these distributed systems are sending events to Kafka, from there we
trigger Unomi Consumers which transform and validate the events properties and
store them in Unomi.
We work in a matter that event publishers are consumer agnostic, meaning
Unomi is just another downstream consumer of events.
We have scenarios of which entities are being created and after a while
being updated. for example: a customer left a review which triggered
ReviewCreate event. for each review we are performing sentiment analysis
asynchronously (after the review was created, we send the text through an NLP
pipeline) which eventually update the review entity with a sentiment score and
triggers the ReviewUpdated event.
We need to be able to store the sentiment score within Unomi, and associate
it with the relevant event that was already registered in Unomi.
We can dig deeper to some of the other use cases if u would like offline :)
nonetheless, the change proposed in this PR is supporting our use case
without breaking the default use cases you guys had in mind while building
Unomi.
10x
Ron
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
