rebase and land

Removed logic from JSX

moved additional one-time setup to parent diff

address jon's feedback

rebase and land

In D7175#214623, @tomek wrote:

Yeah, that would be more reliable, but also more complicated. We have to decide if it makes sense to spend time on it now. At least we should create a task to track that.

addressing jon's feedback

change counter to promise_id

Move logic from message-creator to thread-updaters

remove one-time setup

In D7215#214574, @jon wrote:

I don't feel strongly about the rust code, which is ephemeral anyway.

Can't comment on the jsi code.

Move import

Responded to review

In D7175#214618, @rohan wrote:

In D7175#213494, @tomek wrote:

So basically, this code handles only the pin icon next to a message on message list. And it's not intended to provide data for pinned list, right?

Yeah, exactly!

The only concern is that we probably don't pin messages in transaction. That means that we can successfully update pin status in the db, but fail to create TOGGLE_PIN message. A lot more reliable approach would be to add a field to a message saying that it is pinned.

You're right, I don't believe we pin the messages in a transaction. So the DB for the message gets updated on pin/unpin (pinned and pin_time), and we separately create a message of type === TOGGLE_PIN. So are you suggesting instead of determining isPinned by the messages, we instead determine isPinned by it's state in the DB (pinned = 1 or pinned = 0)?

Simplify isPinned calculation

In D7175#213494, @tomek wrote:

So basically, this code handles only the pin icon next to a message on message list. And it's not intended to provide data for pinned list, right?

Yeah, exactly!

The only concern is that we probably don't pin messages in transaction. That means that we can successfully update pin status in the db, but fail to create TOGGLE_PIN message. A lot more reliable approach would be to add a field to a message saying that it is pinned.

You're right, I don't believe we pin the messages in a transaction. So the DB for the message gets updated on pin/unpin (pinned and pin_time), and we separately create a message of type === TOGGLE_PIN. So are you suggesting instead of determining isPinned by the messages, we instead determine isPinned by it's state in the DB (pinned = 1 or pinned = 0)?

In D7202#214607, @kamil wrote:

Looks good!!

One note to test plan:

Confirm the schema works

1. git checkout pinned_messages
2. Build the app from xcode
3. Connect to the SQLite database and confirm the existence of a pinned_count column

This is not a full test, between steps 2 and 3 you should logout user or make sure it's a fresh install - otherwise, you can not be sure that create_schema was called. Could you verify if it works and amend this to the test plan?

Yeah I had deleted the app and it was the first install, let me fix the test plan to include that so it's clear

Looks good!!

In D7066#214557, @inka wrote:

What designs are you using? The designs I found (here) show the label next to the message.
I also see no comments regarding this, in what I guess is the task this diff is addressing (here)

address feedback

Remove index.js stub

LGTM, ill defer to react/redux people for correctness

I don't feel strongly about the rust code, which is ephemeral anyway.

I'm not able to comment on gradle code, but I couldn't find a better way to do this using just cmake + corrosion + cxxbridge

I think you test plan got cut off

What designs are you using? The designs I found (here) show the label next to the message.
I also see no comments regarding this, in what I guess is the task this diff is addressing (here)

1. Can you separate the codegenned parts and your modifications into separate diffs?
2. For the codegenned diffs, can you list the exact commands you ran to generate the code?

Fix syntax

Add default_value() to sqlite_orm's storage, add default value to schema, and rewrite the check for a pinned_count column to match convention

Intl.Segmenter seems like the best bet! We can figure out the Flow types... worst case we might need to do something like const OurIntl: OurIntlType = (Intl: any); or something.

Perfect!

Accepting with a question. Don't think we need to throw the last result away

Just nits, but requesting changes because some of them are non-obvious and I want to confirm it's implemented right before you land :)

Can you amend the Test Plan to include confirming that no warnings like this are presented: https://github.com/CommE2E/comm/blob/2901fdbf2fe11c8564c13fa3fe2513b8a05f5e29/native/chat/message.react.js#L118-L125

In D7202#214418, @kamil wrote:

In the test plan for the Confirm migration for new clients already with the column works

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

This scenario should never happen, if you have not tested code that is not working properly - we added those checks (IF NOT EXISTS, checking if columns are in the table) because there were some problems in the past and we wanted to avoid crashes as soon as possible.

I think this additional check is okay, like in here but if this code fails on your side without this it means something bad is going on.

Looks like the test flow is not fully correct:

1. Delete the app
2. Add the schema changes
3. Install the app (so the db is constructed from the schema)

And that's how this column is added - it's in create_schema but you don't add migration which means the database version is set to 25. Database version is max of migration indexes.

4. Add the migration

DB version is 25 so migration 26 executes and fails.

5. Rebuild the app
6. Confirm that no error for 'duplicate column' is thrown since we detected the column before adding it

When modifying schema you should always modify and test both create_schema and migrations at once. In this test plan you first modified the schema, then built the app and after this, you added migration.