Details
Restore the account and see the logs.
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| native/cpp/CommonCpp/DatabaseManagers/SQLiteConnectionManager.cpp | ||
|---|---|---|
| 76–83 ↗ | (On Diff #50444) | Unclear to me what the point of this change is. handleSQLiteError already does the SQLITE_OK check, prints to Logger::log, and prints sqlite3_errstr(getOperationResult). Let me know if I'm missing something |
| 133–134 ↗ | (On Diff #50444) | This seems like the only non-logging change. What is its effect? |
| native/cpp/CommonCpp/DatabaseManagers/SQLiteConnectionManager.cpp | ||
|---|---|---|
| 76–83 ↗ | (On Diff #50444) | Right, this can be deleted. |
| 133–134 ↗ | (On Diff #50444) | When the log contains a delete statement for a row that changed since the backup, the operation is still performed. https://www.sqlite.org/session/c_changeset_abort.html |
| native/cpp/CommonCpp/DatabaseManagers/SQLiteConnectionManager.cpp | ||
|---|---|---|
| 127–128 ↗ | (On Diff #50449) | What scenario are you thinking about with this change? Wondering why we want to delete an edited row, and what would have caused the edit |
| native/cpp/CommonCpp/DatabaseManagers/SQLiteConnectionManager.cpp | ||
|---|---|---|
| 127–128 ↗ | (On Diff #50449) | Our DB ops that delete entities perform the operation based on the primary key. So even if the row was edited in any way, we should still delete the row, as that's the expected state after processing this operation. If our log handling is correct, then we shouldn't need to handle this case. But we're seeing some issues with it, so I think that if the intention of the operation was to delete a row identified by a given primary key, we should do that. |
| native/cpp/CommonCpp/DatabaseManagers/SQLiteConnectionManager.cpp | ||
|---|---|---|
| 127–128 ↗ | (On Diff #50449) | Ah, okay. So the case you're considering is:
Makes sense! |