Page MenuHomePhabricator

[native/CommCoreModule] add function check if database is malformed and needs deletion
ClosedPublic

Authored by kamil on Dec 22 2022, 2:49 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 17, 10:58 AM
Unknown Object (File)
Sat, Dec 14, 8:11 AM
Unknown Object (File)
Sat, Dec 14, 8:11 AM
Unknown Object (File)
Sat, Dec 14, 8:11 AM
Unknown Object (File)
Sat, Dec 14, 8:11 AM
Unknown Object (File)
Sat, Dec 14, 8:10 AM
Unknown Object (File)
Sat, Dec 14, 8:05 AM
Unknown Object (File)
Wed, Dec 4, 3:53 PM
Subscribers

Details

Summary

Checks if flag in SecureStore equals SECOND_FAILURE which means database needs deletion.

Test Plan

Call this function from JS and should return true only when database status means that database initialization failed for the second time

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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, 2:16 AM

Is there a premise to implement this functionality in DatabaseManager? We end up calling a method directly from DatabaseManager in CommCoreModule, while in all other places DatabaseManager serves exclusively as a provider of an appropriate query executor.
This differential and the last two implement some functionality in DatabaseManager, that could be implemented in SQLiteQueryExecutor and exposed to other classes via appropriate virtual methods in DatabaseQueryExecutor. This approach:

  1. wouldn't change functionality implemented in this diff stack
  2. fix dependency flow issues from former differentials
  3. make this functionality concise with already established convention that proved to be working well.

Currently we have no plan to replace SQLite with different database type and we can't even try to guess whether we ever will. Moreover, even if one day we need, we might need entirely different functionality than the one implemented in those differential. That said I think it is better to keep methods from last three differentials in more specific, lower-level class (SQLiteContextProvider) and expose them in the same way other methods are.

This revision now requires changes to proceed.Dec 26 2022, 2:16 AM
kamil requested review of this revision.Dec 30 2022, 5:01 AM

I have a different understanding of the flow here and how things should cooperate here, so let me ask a few questions to establish a common point of view. Sorry if I am not correct in my understanding.

Is there a premise to implement this functionality in DatabaseManager? We end up calling a method directly from DatabaseManager in CommCoreModule, while in all other places DatabaseManager serves exclusively as a provider of an appropriate query executor.

Do you think that serving query executor is the only responsibility of DatabaseManager?
While working on this I discussed this problem with @tomek and ideally, we should have a third layer above those (right now we have only one database so what we have is sufficient):

  • providing database manager eg. some kind of DatabaseProvider class (not present)
  • DatabaseManager - providing query executor, managing database, database file and its lifetime, handling initialization etc. (I mentioned the same in D5989's summary)
  • QueryExecutor - responsible ONLY for querying the database, operating on its schema using raw SQL or ORM.

This differential and the last two implement some functionality in DatabaseManager, that could be implemented in SQLiteQueryExecutor and exposed to other classes via appropriate virtual methods in DatabaseQueryExecutor.

How checking if database was properly created, and looking into the secure store is connected to the query executor or to be more precise with SQLiteQueryExecutor? What queries it executes, while not doing anything with DB itself but checking Secure Store flag?

Currently we have no plan to replace SQLite with different database type and we can't even try to guess whether we ever will. Moreover, even if one day we need, we might need entirely different functionality than the one implemented in those differential. That said I think it is better to keep methods from last three differentials in more specific, lower-level class (SQLiteContextProvider) and expose them in the same way other methods are.

I got you, and this will make those diffs even easier to implement, but I think by making this we drastically mix responsibilities in this architecture, DatabaseManager only provides an executor- while the query executor does everything, like managing the database...

lower-level class (SQLiteContextProvider) and expose them in the same way other methods are.

Did you mean SQLiteQueryExecutor?

marcin added a reviewer: tomek.

Do you think that serving query executor is the only responsibility of DatabaseManager?

After a second look, I think I should agree with this point of view. There is no reason we can't call something else than DatabaseManager::getQueryExecutor()... in CommCoreModule.

This revision is now accepted and ready to land.Jan 2 2023, 4:08 AM