issue: ENG-8783
Details
Details
- Reviewers
tomek kamil - Commits
- rCOMM86b47afb4189: [native][web] Fetch related messages for search
Tested by commenting out isThreadThin check, and commenting out extractKeyserverIDFromIDOptional(messageInfo.threadID) check in getMessageSearchStoreOps, and setting threadMessageInfos in createChatMessageItems to empty array to make sure messages from redux are not being used.. This allowed me to treat a thin thread as if it were thick, and execute local search on it.
Tested that edits and reactions show up in search results
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| native/cpp/CommonCpp/DatabaseManagers/SQLiteQueryExecutor.cpp | ||
|---|---|---|
| 2598–2604 ↗ | (On Diff #42725) | Should we perform these in a single transaction? |
| 2606–2609 ↗ | (On Diff #42725) | Should we sort the messages? Results from both processMessagesResults and getRelatedMessagesForSearch are sorted, but their concatenation isn't. |
| native/cpp/CommonCpp/DatabaseManagers/SQLiteQueryExecutor.cpp | ||
|---|---|---|
| 2598–2604 ↗ | (On Diff #42725) | We talked about this with Tomek and Kamil and it doesn't have to because we access the db from one thread and synchronously, on both web and native. So there is no threat of some insert being executed between those two selects. And two selects don't need to be run in one transaction. |
| 2606–2609 ↗ | (On Diff #42725) | This data is sorted on the js side in createChatMessageItems by sortMessageInfoList |
| native/cpp/CommonCpp/DatabaseManagers/SQLiteQueryExecutor.cpp | ||
|---|---|---|
| 2631 | Why do we have i + 1 here? | |
| native/cpp/CommonCpp/DatabaseManagers/SQLiteQueryExecutor.cpp | ||
|---|---|---|
| 2631 | This was copied from your code in getAllEntitiesByPrimaryKeys. | |