[CIS-692] Implement Channel Truncating #864
Conversation
VojtaStavik
added
the
🌐 SDK: StreamChat (LLC)
| controller.messages.forEach { | ||
| print($0.createdAt) | ||
| } |
| override func willSave() { | ||
| super.willSave() | ||
|
|
||
| // Change to the `trunctedAt` value have effect on messages, we need to mark them dirty manually | ||
| // to triggers related FRC updates | ||
| if changedValues().keys.contains("truncatedAt") { | ||
| messages | ||
| .filter { !$0.hasChanges } | ||
| .forEach { | ||
| // Simulate an update | ||
| $0.willChangeValue(for: \.id) | ||
| $0.didChangeValue(for: \.id) | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
I didn't understand what's going on here... What are the updates we need to trigger?
There was a problem hiding this comment.
I created CIS-695 which improves this. It's the same trick we use for attachments and messages. Fetched results controller doesn't observe changes in related objects, even when you specify them in the predicate. So for example:
predicate = ALL messages WHERE message.createdAt > channel.truncatedAt
will get evaluated properly when you fetch the first time. However, when you change the channel.truncatedAt value, the FRC ignores it because it observers only changes to MessageDTO entity. This way we force the FRC to re-evaluate the predicate and update the results.
| @@ -260,3 +260,16 @@ private extension Logger { | |||
| } | |||
| } | |||
| } | |||
|
|
|||
| public extension Data { | |||
| @@ -36,7 +36,9 @@ enum EventType: String, Codable { | |||
| case channelDeleted = "channel.deleted" | |||
| /// When a channel was hidden. | |||
| case channelHidden = "channel.hidden" | |||
|
|
|||
| /// When a channel was trucnated. | |||
There was a problem hiding this comment.
| /// When a channel was trucnated. | |
| /// When a channel was truncated. |
| // Simulate `deleteChannel(cid:, completion:)` call | ||
| // Simulate `truncateChannel(cid:, completion:)` call |
VojtaStavik
force-pushed
the
CIS-692-channel-truncating
branch
from
2f7eb4c to
0eae013
Compare
| } | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Files should have a single trailing newline.trailing_newline Logger.swift:276 |
Generated by 🚫 Danger |
Codecov Report
@@ Coverage Diff @@
## main #864 +/- ##
==========================================
- Coverage 87.35% 86.80% -0.55%
==========================================
Files 229 230 +1
Lines 8680 8744 +64
==========================================
+ Hits 7582 7590 +8
- Misses 1098 1154 +56
Continue to review full report at Codecov.
|
| } | ||
| } completion: { error in | ||
| if let error = error { | ||
| log.error("Failed to update message reaction in the database, error: \(error)") |
There was a problem hiding this comment.
(While copying your code for my Watcher Middleware) I've realized you forgot to change the error message here 
The comment suggested that this was there for some purpose but all tests still pass so I guess it's ok :)
VojtaStavik
force-pushed
the
CIS-692-channel-truncating
branch
from
1d4d142 to
87b6284
Compare
When the channel is truncated, it means all messages sent before the truncation disappear. When you query the channel, it has no messages and even the
last_message_atvalue is reset.Possible ways to implement this locally
a) Delete all messages from the DB -> hard deleting entities from CoreData is not trivial because of our complex data model scheme. This would be the most complicated way to implement this feature. 🔴
b) Soft-delete messages by
message.type = .deleted-> this is less complex but not ideal. Deleted messages have different semantics from the truncated messages, especially when it's the messages sent by the current user. Almost there... 🔴c) Do it the same way the backed does it -> I added
truncatedAtfield toChannelDTOand adjusted the message predicates to ignore the message created before this date. This solution is the most simple one and works nicely ✅Issues
We will have to introduce some kind of DB cleanup worker that will take care of "physically" removing the truncated messages from the DB. This worker can run only when there are no observers attached to the DB in order to prevent invalid updates. However, the clean-up worker is needed anyway otherwise the DB size would just grow and grow with more incoming messages and new channels.
Our current custom layout crashes when all messages are removed. I found the issue but the fix was not obvious. I didn't want to spend more time on it since @olejnjak is working on fixing the layout anyway.