Hello,
I am starting working on the Thread/changes topic, and I think I should
discuss how to implement this topic with you.
After looking at Thread/changes specs, I think we should add thread
event-oriented support to our Event Bus.
I propose 3 events: Thread create, thread update and thread destroy. These
events should store which data is still a topic, but at least they need to
store changed threadId.
A thread create can be easily emitted when we decide a message should have
a new threadId. But we need to distinguish when thread update and thread
destroy event happens.
To handle that, I propose a table store 1 threadId to many messageId. This
table can be used for getThread API, but it’s mainly easy to find changes
about a thread for Thread/changes topic which we are discussing.
ThreadIdToMessageIdTable? : threadId timeuuid, messageId timeuuid.
Partition key: threadId and clustering key: messageId.
I suppose some cases how we interact with this table and event bus system:
-
When we decide a message should have a new threadId => store data to
ThreadIdToMessageIdTable and emit ThreadCreate event.
-
When we decide a message should have a old threadId => store data to
ThreadIdToMessageIdTable and emit ThreadUpdated event.
-
When we delete a message (under DeleteMessageListener hood), there will
be 2 sub-case:
-
delete not the last message in that thread: we delete related data in
ThreadIdToMessageIdTable and emit ThreadUpdate event.
-
delete the last message in that thread: we delete related data in
ThreadIdToMessageIdTable and emit ThreadDestroy event.
So how do we know if it's the last message in that thread or not? First, we
need to be able to lookup threadId by messageId by easily add threadId to
existed ThreadLookupTable. After each message deletion, we will select and
count the number of records by that threadId from ThreadIdToMessageIdTable.
If there still are records of that thread, we know that is an update event.
If there are no records anymore, we know that is a destroyed event.
Now we have to handle these thread events. I propose using
ThreadChangesListener to handle these by calling ThreadChangesRepository/
ThreadChangesRepositoryDAO. Which APIs do we need and what is the
ThreadChangesTable’s structure is still a topic. For now, I can say it can
take inspiration from MailboxChanges.
The above is my outline ideas. Please have a look and do some discussion
together.
Best regards,
Quan
