Details
Check that putMessageItem, findMessageItem, removeMessageItem returns expected results.
Diff Detail
- Repository
- rCOMM Comm
- Branch
- D3117
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
services/tunnelbroker/docker-server/contents/server/src/Database/DatabaseManager.cpp | ||
---|---|---|
181–184 ↗ | (On Diff #9326) | In putSessionItem and in blob service we use a different approach request.AddItem( DeviceSessionItem::FIELD_CHECKPOINT_TIME, Aws::DynamoDB::Model::AttributeValue( std::to_string(item.getCheckpointTime())) We call AttributeValue instead of calling SetN method. Could you clarify which approach is correct and make sure to be consistent? |
services/tunnelbroker/docker-server/contents/server/src/Database/DatabaseManager.cpp | ||
---|---|---|
181–184 ↗ | (On Diff #9326) |
If we call AttributeValue the DynamoDB saves the value as a string (it's same as calling SetS). If we need to save the value as an integer we should call SetN. |
services/tunnelbroker/docker-server/contents/server/src/Database/DatabaseManager.cpp | ||
---|---|---|
181–184 ↗ | (On Diff #9326) | Is it safe to save uint64_t by using this method? In the documentation you linked I can't see that this method has this (or long long) variant. So it looks like we're going to cast the value to int - we should definitely fix that. |
services/tunnelbroker/docker-server/contents/server/src/Database/DatabaseManager.cpp | ||
---|---|---|
181–184 ↗ | (On Diff #9326) | What's wrong with storing it in the dynamo as a string? I think we should always work with strings when dealing with dynamo DB, even GetN returns a string. The first thing is what Tomek mentioned about numeric data types - doesn't look safe. |
services/tunnelbroker/docker-server/contents/server/src/Database/DatabaseManager.cpp | ||
---|---|---|
181–184 ↗ | (On Diff #9326) |
I thought that the point why we have SetS and SetN while the function returns and gets string: it's because of how DynamoDB stores it. If we call SetN it will cast and store the value as a 64-bit integer. But when I dig into it I've found that SetN is a simple helper to convert the numbers to the string... And this comment confirms this too. That's why there is no any point to use SetN anywhere. |