Change Details

We need to add the pinned_count column to SQLite threads table, so when we (in the next diff) try to store pinnedCount in ThreadInfos, the ClientDB will have the pinned_count. As mentioned in the test plan: > I'm not entirely sure if we really even need to consider a case where a new client will already have the column besides me in development work, so I can also just remove that check entirely and just add the column Part of https://linear.app/comm/issue/ENG-3396/store-the-number-of-pinned-messages-in-threadinfo Depends on D7199

We need to add the pinned_count column to SQLite threads table, so when we (in the next diff) try to store pinnedCount in ThreadInfos, the ClientDB will have the pinned_count. As mentioned in the test plan: > I'm not entirely sure if we really even need to consider a case where a new client will already have the column besides me in development work, so I can also just remove that check entirely and just add the column. I ran into this inconsistency while working off of my modified schema and running a migration on top of that Part of https://linear.app/comm/issue/ENG-3396/store-the-number-of-pinned-messages-in-threadinfo Depends on D7199

We need to add the pinned_count column to SQLite threads table, so when we (in the next diff) try to store pinnedCount in ThreadInfos, the ClientDB will have the pinned_count. As mentioned in the test plan: > I'm not entirely sure if we really even need to consider a case where a new client will already have the column besides me in development work, so I can also just remove that check entirely and just add the column. I ran into this inconsistency while working off of my modified schema and running a migration on top of that Part of https://linear.app/comm/issue/ENG-3396/store-the-number-of-pinned-messages-in-threadinfo Depends on D7199