In D5453#161021, @tomek wrote:

@kamil could you give it a review and add me as blocking when the diff is ready?

In D5377#160948, @marcin wrote:

(If the app will run into issues like those described in previous links in this time another thread could already updated the version).
If another thread will do it within getting the version and performing migration (not in the transaction) we do not run into issues because setting journal mode is an idempotent operation.

Such scenario is currently impossible. Different threads access database via GlobalDBSingleton. They put tasks (in the form of C++ lambdas) to the queue, and dedicated database thread executes them in FIFO manner (by consuming queue). This way tasks scheduled to GlobalDBSingleton are executed atomically. SQLiteQueryExecutor is thread_local, so every thread will instantiate its own SQLiteQueryExecutor (and hence schedule migrate() to be executed on GlobalDBSingleton), but due to atomicity of database tasks it is not possible that some migrations will be performed by one's thread SQLiteQueryExecutor constructor while others by another's.

Those changes look OK, but we must be aware that they do not resolve potential issue but rather prepare code to a situation if we enable multithreaded access to SQLite and resign from GlobalDBSingleton at all.
Requesting changes to make sure this comment is read and addressed.

In D5379#160340, @atul wrote:

Back to your queue until D5378 is addressed (let me know if the issues I'm seeing aren't accurate though)

In D5378#160333, @atul wrote:

I tried the following on my local machine

1. Created a SQLite3 DB file
2. Ran the query

and got the following:

Query 1 ERROR: no such table: main.messages

After running it again, I got the following:

Query 1 OK

I tried this twice to make sure the issue was reproducible. It looks like this query will always fail the first time it's run?

Feel free to re-request review if there's something I'm missing or the results I'm seeing are inaccurate.

In D5377#160412, @atul wrote:

Does the following stack of two commits achieve both goals D5440 D5441?

In D5376#160623, @marcin wrote:

Same concerns and questions as in D5375.

In D5375#160617, @marcin wrote:

In the future there will be a need to get the database version in different places, that being said extracting logic to separate function.

What do you mean by "other" places? If you think about calling this function from different places inside SQliteQueryExecutor then this differential is fine and ready to be accepted. But if you want to call this function somewhere in C++ outside of SQliteQueryExecutor, then we have a few problems:

1. This function is not defined in SQLiteQueryExecutor.h neither as a class method nor free function. So we are not able to call it outside of SQLIteQueryExecutor
2. If we want to call this function outside of SQLiteQueryExecutor.h should it be free function or method? If method then we also need to introduce it as virtual in DatabaseQueryExecutor abstract class

I need your answer regarding "other places" in the code we want to call this function from and your thoughts on 1 and 2 if you want to call this function outside of SQLiteQueryExecutor.

In D5377#160227, @atul wrote:

1. We want to ROLLBACK when a migration fails.

I think we could just do something like this: https://phab.comm.dev/D5433?

In D5379#159648, @atul wrote:

Back to your queue until D5377 is updated

In D5377#159644, @atul wrote:

I think this needs to be cleaned up some more before it's ready for review

remove unnecessary line

In D5375#159611, @atul wrote:

Looks good, can we maybe move get_database_version() closer to where it's used though (it's like 200 lines above the only usage)? Feel free to leave as is if you had a reason to place it where you did.

setting version for 99999 because sending source was not released yet and not sure which version to use

check for falsey input on older client

use ON DUPLICATE KEY, use map, add newline

fix formating, add new line, remove const

fix import

fix spacing issue, add new line, remove const

thanks for responding to comments @ashoat!

update query formating

add new line below // @flow

update code structure

If we set journal mode here do we also need to set it when running migrations? Isn't calling enable_write_ahead_logging_mode redundant now? I just want to make sure we do not perform redundant operations.

set journal_mode using sqlite_orm only on fresh install

update ROLLBACK

add IF NOT EXISTS for messages_idx_thread_time

set journal_modeusing sqlite_orm

In D5260#155039, @ashoat wrote:

This is a really bad idea. You're going to cause all existing native clients to crash when they attempt to log in.

leave sorce optional on keyserver

I left some comments but it'll be good if one of the senior reviewers take a look if my suggestions were correct.

rebase

rebase

LogInActionSourceType -> LogInActionSource

clean imports, rename constants