Hi Benoit, Today I did try to think of a more optimized way. I did have some ideas but it comes with some challenges.
At first, I have a look at EmailChanges to see if I can reuse this for thread changes. The good thing is EmailChanges be produced after Added and Expunged which contains MessageMetaData(have threadId). But the first problem is EmailChanges can be produced also from other events like FlagsUpdated which do not change thread and the second problem here a create/update/destroy messageId is not corresponding with a thread event. So I think we still need a separate ThreadChanges. My idea is that we need a 1 thread - n messageId table ( ThreadIdToMessageIdTable) . We need to handle thread changes when Added, Expunged and MailboxDeletion events happen. *Added*: Before emit Added event, we insert data to this table. MailboxChangeListener will listen to Added, then get a Set<ThreadId> from this. We need to qualify which threadId is created, which is updated by doing a query to ThreadIdToMessageIdTable that ask the records number of that thread: - If number = 1 => created - If number > 1 => updated This way should work well with an Added event for each message. I see Added event emitted when adding a message, but I doubt why in Added structure we use Map and Collection<MessageUid>? If Added event comes with multiple messages, the above algorithm will not work (in case there are 2 messages both come in a new thread then that thread could be counted as updated). *Expunged*: The idea is to query to ThreadIdToMessageIdTable and ask distinct threadId: - If this threadId is not in the result set => destroyed - If this threadId is in result set => updated The problem is we need to delete data in ThreadIdToMessageIdTable before doing the query. It should happen in DeleteMessageListener, but I think DeleteMessageListener will not really happen before MailboxChangeListener. The other choice is to delete that data in MailboxChangeListener, but I am not sure this is a good idea. *MailboxDeletion*: Before deletion as above, we need to get all messageId in that mailbox => get a corresponding Set<ThreadId>. Then we do delete data in ThreadIdToMessageIdTable following MailboxDeletion. The idea is to query to ThreadIdToMessageIdTable and ask for distinct threadId: - If this threadId is not in the result set => destroyed - If this threadId is in result set => updated In conclusion, this idea may work but comes with some problems. How do you think about this? Best regards, Quan Vào Th 3, 3 thg 8, 2021 vào lúc 17:17 [email protected] < [email protected]> đã viết: > Hello Quan, > > Your design proposal would definitly work and I would qualify it of a > straightforward solution. > > With my "efficiency" hat on, I am not really fan of having new events. > > I was really surprise to discover that JMAP submissions (draft protocol) > of a single message did result in the submission of 10 events and had a > major on overall performance. > > My mindset today would more be to 'shrink' that count of events rather > than increasing them. > > Don't we have existing data structures that could be reused as is, or > slightly modified, to answer the following questions? > - A thread is created? > - A thread is updated? > > Cheers, > > Benoit > > On 03/08/2021 16:31, Quan tran hong wrote: > > 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. > I am not sure this distinction is critical: a destroyed thread is just a > thread with no more messages associated to it. > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
