Details
- Reviewers
tomek - Commits
- rCOMM3667a7b5bd16: [services] Backup - Implement generating holder
Services still build
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
services/backup/src/Tools.cpp | ||
---|---|---|
24–34 ↗ | (On Diff #12627) | If we modify the order of arguments we can have only one function with a default value. Additionally, we can have the same schema for both cases, so that it's easier to parse it in the future (if we ever need to). |
services/backup/src/Tools.cpp | ||
---|---|---|
24–34 ↗ | (On Diff #12627) | Good point, I missed that. But I think it will be more readable to have resourceID next to backupID, so we could do: std::string generateHolder( const std::string &blobHash, const std::string &backupID, const std::string &resourceID = "" ) { |
services/backup/src/Tools.cpp | ||
---|---|---|
28–33 ↗ | (On Diff #12837) |
What do you think about the second part of my comment where I suggested that we should have the same number of sections in id, even when resourceID is empty? |
services/backup/src/Tools.cpp | ||
---|---|---|
28–33 ↗ | (On Diff #12837) | At first I thought that aaa::bbb would look weird with :: but the argument about the parsing makes sense. Sorry I didn't implement this right away. I'm going to change this. Thanks. |
fix invalid update, generate the same holder no matter if the resourceID is empty or not
How is application going to function if this error occurs? In most places we the runtime error to kill the app if database operation fails since application is not going to work correctly. I just want to know whether it is also the case here.