Page MenuHomePhabricator

[services] Tunnelbroker - Changes to store the `deviceType` as an int instead of string
ClosedPublic

Authored by max on Nov 8 2022, 10:00 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 17, 5:28 AM
Unknown Object (File)
Sat, Dec 14, 5:22 PM
Unknown Object (File)
Fri, Dec 13, 11:50 PM
Unknown Object (File)
Mon, Nov 25, 12:48 AM
Unknown Object (File)
Sun, Nov 24, 11:51 AM
Unknown Object (File)
Sun, Nov 24, 11:50 AM
Unknown Object (File)
Sun, Nov 24, 11:50 AM
Unknown Object (File)
Sun, Nov 24, 11:50 AM

Details

Summary

This diff introduces changes to the type for deviceType field from a string to an integer.
The deviceType is an enum type in our proto file. The values come from the gRPC requests as an integer enum representation, Rust Tonic proto file compiler also creates the enum representation as an integer.

Before switching to Rust we are using the string as a storing type of the enum value in the database because of the enum matching was done using strings on the C++ side.
Now it doesn't make sense to store the enum value as a string in a database, because the matching of the enum in Rust uses integer representation as well as in gRPC implementation itself.

Linear task: ENG-2059

Test Plan

The legacy C++ codebase is successfully built.
The usage of the functions is in D5490 and it successfully built

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

max held this revision as a draft.
max edited the test plan for this revision. (Show Details)
max added a reviewer: marcin.
tomek requested changes to this revision.Nov 9 2022, 8:22 AM
tomek added inline comments.
services/tunnelbroker/src/libcpp/src/Database/DatabaseManager.cpp
43–44 ↗(On Diff #18222)

This confuses me a bit. Why do we need to transform it to string?

services/tunnelbroker/src/libcpp/src/Database/DeviceSessionItem.cpp
64–66 ↗(On Diff #18222)

Why this is different then reading checkpointTime?

services/tunnelbroker/src/libcpp/src/Database/DeviceSessionItem.h
16 ↗(On Diff #18222)

Is size_t the right type? How many bytes does this value occupy in the db?

services/tunnelbroker/src/libcpp/test/DatabaseManagerTest.cpp
144 ↗(On Diff #18222)

Is there a way to use an enum instead of magic numbers?

This revision now requires changes to proceed.Nov 9 2022, 8:22 AM
max marked 4 inline comments as done.
max added inline comments.
services/tunnelbroker/src/libcpp/src/Database/DatabaseManager.cpp
43–44 ↗(On Diff #18222)

This confuses me a bit. Why do we need to transform it to string?

This a long story, but the AWS SDK storing numbers (and returning numbers as strings) even when we are using GetN (get number). That's confusing and we have discussions with Karol and you last year I think, about how to solve this, but that's how AWS-CPP SDK works. Numbers as string 🤷‍♂️

services/tunnelbroker/src/libcpp/src/Database/DeviceSessionItem.cpp
64–66 ↗(On Diff #18222)

Why this is different then reading checkpointTime?

GetS and GetN both returns string despite the fact that GetN - Get Number. I just followed the convention that despite we got the string we expecting this to be converted into the number. But I can use GetS and there are no differences.

services/tunnelbroker/src/libcpp/src/Database/DeviceSessionItem.h
16 ↗(On Diff #18222)

Is size_t the right type? How many bytes does this value occupy in the db?

We are storing a small number here but I've used size_t for compatibility with the Rust CXX types. We can use here some smaller int but later we still should convert it into compatible size_t bigger type and static casting is costly (I think more costly than just storing in a bigger int).

services/tunnelbroker/src/libcpp/test/DatabaseManagerTest.cpp
144 ↗(On Diff #18222)

Is there a way to use an enum instead of magic numbers?

This is a gRPC enum from the proto file. As we've changed the gRPC server to Rust we've removed the proto file compilation into C++ headers, the only way to use the enum here is to redefine it manually. I don't think this is a good idea, because of the switching to Rust and we should maintain this manually added enum according to the proto file in this legacy C++ code. I think the better way here is to add a comment describing what the number is and where it came from.

max marked 4 inline comments as done.

Adding a comment to the DeviceTypes enum mubers.

tomek requested changes to this revision.Nov 17 2022, 2:33 AM
tomek added inline comments.
services/tunnelbroker/src/libcpp/src/Database/DeviceSessionItem.cpp
64–66 ↗(On Diff #18222)

We declared deviceType as size_t but convert to it using stoll which returns long long. Can we make this more consistent?

services/tunnelbroker/src/libcpp/test/DatabaseManagerTest.cpp
144 ↗(On Diff #18222)

I don't think this is a good idea, because of the switching to Rust and we should maintain this manually added enum according to the proto file in this legacy C++ code. I think the better way here is to add a comment describing what the number is and where it came from.

I strongly disagree. So now, if the gRPC enum changes, he have to search the codebase for all its usages and update it. If we had a const / enum defined, we could update only it. There's no reason to encode something as a comment when we can have a named constant with it.

This revision now requires changes to proceed.Nov 17 2022, 2:33 AM

Adding of the DeviceTypes enum. Change to use stoul to convert from the database's integer to device type.

max added inline comments.
services/tunnelbroker/src/libcpp/src/Database/DeviceSessionItem.cpp
64–66 ↗(On Diff #18222)

We declared deviceType as size_t but convert to it using stoll which returns long long. Can we make this more consistent?

Good catch, thanks @tomek!
I think more closest to the size_t here is to use stoul instead. I've made this change.
We can't use a static cast here like static_cast<size_t> or any other castings other than st** functions. Other methods require streams and additional variables which is overkill here. We can possibly use a lexical_cast from boost, but we don't want to add an additional dependency for this as we already have a sto** functions in the standard library.

services/tunnelbroker/src/libcpp/test/DatabaseManagerTest.cpp
144 ↗(On Diff #18222)

I don't think this is a good idea, because of the switching to Rust and we should maintain this manually added enum according to the proto file in this legacy C++ code. I think the better way here is to add a comment describing what the number is and where it came from.

I strongly disagree. So now, if the gRPC enum changes, he have to search the codebase for all its usages and update it. If we had a const / enum defined, we could update only it. There's no reason to encode something as a comment when we can have a named constant with it.

Ok, that makes sense.
I've added an enum DeviceTypes with the devices types, now we are using an enum without numbers.

tomek added inline comments.
services/tunnelbroker/src/libcpp/src/Database/DeviceSessionItem.h
36 ↗(On Diff #18525)

Do we really skip 2?

This revision is now accepted and ready to land.Nov 18 2022, 3:04 AM
max marked 2 inline comments as done.

Fixing enum discriminant number for the KEYSERVER.

max added inline comments.
services/tunnelbroker/src/libcpp/src/Database/DeviceSessionItem.h
36 ↗(On Diff #18525)

Do we really skip 2?

No, that's a bug! Thanks, @tomek for catching this!