Page MenuHomePhabricator

[native] add function to set database status after successful structure creation
ClosedPublic

Authored by kamil on Dec 22 2022, 2:48 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Nov 12, 2:57 AM
Unknown Object (File)
Fri, Nov 1, 5:33 AM
Unknown Object (File)
Wed, Oct 30, 7:57 AM
Unknown Object (File)
Wed, Oct 30, 7:57 AM
Unknown Object (File)
Wed, Oct 30, 7:57 AM
Unknown Object (File)
Wed, Oct 30, 7:57 AM
Unknown Object (File)
Wed, Oct 30, 7:57 AM
Unknown Object (File)
Wed, Oct 30, 7:57 AM
Subscribers

Details

Summary

Setting Secure Store flag that database structure is properly created

Test Plan

After successful migration process DatabaseManagerStatus should equals WORKABLE

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

kamil held this revision as a draft.
kamil published this revision for review.Dec 22 2022, 3:31 AM
marcin requested changes to this revision.Dec 26 2022, 1:59 AM

This looks like an inaccurate dependency flow to me. DatabaseManager provides getQueryExecutor method that allows to execute database queries in a way that is agnostic of the type of database used. This means it is an abstraction above SQLiteQueryExecutor, so SQLiteQueryExecutor should not call its methods. Looking at this differential, migrate() of SQLiteQueryExecutor is the only place we call this function from. Perhaps we could implement it here? Or even insert its code directly into relevant places in migrate method (due to its simplicity? Necessary constants to implement this method could be moved to DatabaseQueryExecutor header file or even refactored to some new common header file with database-related constants.

This revision now requires changes to proceed.Dec 26 2022, 1:59 AM
kamil requested review of this revision.Dec 30 2022, 5:02 AM

This looks like an inaccurate dependency flow to me. DatabaseManager provides getQueryExecutor method that allows to execute database queries in a way that is agnostic of the type of database used. This means it is an abstraction above SQLiteQueryExecutor, so SQLiteQueryExecutor should not call its methods. Looking at this differential, migrate() of SQLiteQueryExecutor is the only place we call this function from. Perhaps we could implement it here? Or even insert its code directly into relevant places in migrate method (due to its simplicity? Necessary constants to implement this method could be moved to DatabaseQueryExecutor header file or even refactored to some new common header file with database-related constants.

Yes, you're correct, it was a really bad idea to call DatabaseManager's method from the SQLiteQueryExecutor level. But having in mind what I've pointed in this comment: https://phab.comm.dev/D5993#183452 I would suggest a slightly different approach.
Maybe it'll be better to call it after we successfully create a query executor (thread_local variable) which will mean that DB structure is not malformed, in getQueryExecutor() function, probably with adding some variable to DatabaseManager to avoid writing to secure store each time getQueryExecutor is called. What do you think?

In D5992#183457, @kamil wrote:

This looks like an inaccurate dependency flow to me. DatabaseManager provides getQueryExecutor method that allows to execute database queries in a way that is agnostic of the type of database used. This means it is an abstraction above SQLiteQueryExecutor, so SQLiteQueryExecutor should not call its methods. Looking at this differential, migrate() of SQLiteQueryExecutor is the only place we call this function from. Perhaps we could implement it here? Or even insert its code directly into relevant places in migrate method (due to its simplicity? Necessary constants to implement this method could be moved to DatabaseQueryExecutor header file or even refactored to some new common header file with database-related constants.

Yes, you're correct, it was a really bad idea to call DatabaseManager's method from the SQLiteQueryExecutor level. But having in mind what I've pointed in this comment: https://phab.comm.dev/D5993#183452 I would suggest a slightly different approach.
Maybe it'll be better to call it after we successfully create a query executor (thread_local variable) which will mean that DB structure is not malformed, in getQueryExecutor() function, probably with adding some variable to DatabaseManager to avoid writing to secure store each time getQueryExecutor is called. What do you think?

This approach sounds reasonable to me. When implementing this approach it might be helpful to consider https://en.cppreference.com/w/cpp/thread/once_flag and https://en.cppreference.com/w/cpp/thread/call_once (an easy way to make something idempotent in C++).

marcin requested changes to this revision.Jan 2 2023, 4:09 AM

Requesting changes until mutually agreed approach that was discussed above is implemented.

This revision now requires changes to proceed.Jan 2 2023, 4:09 AM
marcin added a reviewer: tomek.
tomek added inline comments.
native/cpp/CommonCpp/DatabaseManagers/DatabaseManager.cpp
21–23

Maybe add a comment explaining that creating an instance means that the migrations succeeded and we can assume the db is usable.

61

Do we need the curly brackets?

native/cpp/CommonCpp/DatabaseManagers/DatabaseManager.h
10

We should import it from std in this file

This revision is now accepted and ready to land.Jan 10 2023, 10:52 AM

add missing #include <mutex> and comment

native/cpp/CommonCpp/DatabaseManagers/DatabaseManager.cpp
61
native/cpp/CommonCpp/DatabaseManagers/DatabaseManager.h
10

sure, adding #include <mutex>