Page MenuHomePhabricator

[services] Lib - Tunnelbroker - Use sources
ClosedPublic

Authored by karol on May 10 2022, 4:27 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Nov 5, 3:14 PM
Unknown Object (File)
Sun, Oct 20, 10:47 AM
Unknown Object (File)
Oct 13 2024, 2:20 PM
Unknown Object (File)
Oct 13 2024, 2:20 PM
Unknown Object (File)
Oct 13 2024, 2:20 PM
Unknown Object (File)
Oct 13 2024, 2:15 PM
Unknown Object (File)
Sep 10 2024, 8:57 AM
Unknown Object (File)
Sep 5 2024, 1:13 PM

Details

Summary

Depends on D3988

Linking header/source files from the "lib" directory to the tunnelbroker. I had to perform some operations in order to avoid having compile errors. Maybe I missed something but I don't think it's possible to have a smaller changeset after attaching the sources from "lib".

Test Plan

You should be able to build tunnelbroker properly

cd services
yarn run-tunnelbroker-service

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

max added inline comments.
services/tunnelbroker/CMakeLists.txt
60 ↗(On Diff #12491)

Nice catch!

services/tunnelbroker/src/Database/DeviceSessionItem.cpp
86 ↗(On Diff #12491)

Why we are not using std::sring here? Seems we are return a simple string.

services/tunnelbroker/src/Database/DeviceSessionItem.h
34–35 ↗(On Diff #12491)

Maybe we should change this to use Name and Value suffix. It's not obvious now what it returns.

services/tunnelbroker/src/Database/MessageItem.h
32 ↗(On Diff #12491)

Same question here:
Does it seem like PrimaryKey can have only a string, why don't you use it? Despite PrimaryKeyValue is not.
If the PrimaryKeyValue is a complex structure we should name it Values or Struct.
It seems the naming needs to be changed, it's kind of misleading here at my look.

This revision now requires changes to proceed.May 10 2022, 11:21 PM
karol added inline comments.
services/tunnelbroker/src/Database/DeviceSessionItem.cpp
86 ↗(On Diff #12491)

Maybe in this case we do return a simple string but this is only because you don't use sort keys. If we ever want to use them, this will come beneficial to us. It's better to use methods from Item.h.

services/tunnelbroker/src/Database/DeviceSessionItem.h
34–35 ↗(On Diff #12491)

We can do this, but I think it would be better to do this in a follow-up as it appears in blob, backup, tunnelbroker, and lib, so it's a bit beyond this revision.

services/tunnelbroker/src/Database/MessageItem.h
32 ↗(On Diff #12491)

Same question here:
Does it seem like PrimaryKey can have only a string, why don't you use it? Despite PrimaryKeyValue is not.

Same answer as above. Please, note how the inheritance of Item.h works across services.

If the PrimaryKeyValue is a complex structure we should name it Values or Struct.
It seems the naming needs to be changed, it's kind of misleading here at my look.

Where does this come from? Sorry, but this sounds weird. PrimaryKeyValue is one of the simples structs possible: 2 fields, 2 constructors. Most of the classes in our codebase are more complex than that. Similarly, you could say we should rename all classes like this, so instead DatabaseManager we should do DatabaseManagerClass (inb4: class is almost the same thing as struct).

I think naming's fine.

services/tunnelbroker/src/Database/DeviceSessionItem.h
34–35 ↗(On Diff #12491)

When a diff reviewer gives you a comment that applies to other places as well, I think you can reduce the amount of work for the reviewer (who has to track your work across diffs) by doing one of two things:

  1. (Preferred) respond to the request immediately by making the change
    • Then either submit a diff with the changes to other files, and then link it from the original diff
    • Or create a Linear task for the changes to other files, and link it from the original diff
    • Either way you should be linking something, and either way you should write down the list of files somewhere
  2. (Alternative if making the change in only one place breaks the build / causes a crash / etc.)
    • Don't update the current diff but do the other thing (either link the Linear task or the follow-up diff)

Some high-level rules:

  1. If you agree with the request, you should do whatever possible to respond to the request in the current diff
  2. You should never defer work without linking either a follow-up diff or a precise Linear task that directly talks about the thing being requested
services/tunnelbroker/src/Database/DeviceSessionItem.h
34–35 ↗(On Diff #12491)

ok, sorry you're right

tomek added inline comments.
services/tunnelbroker/src/Database/DeviceSessionItem.cpp
86 ↗(On Diff #12491)

Another benefit is that we can easily distinguish between PrimaryKey and PrimaryKeyValue. If we used just strings, it would be easier to make a mistake.

services/tunnelbroker/src/Tools/AwsTools.cpp
19–28 ↗(On Diff #12491)

Was this function unused, or this diff changed something which allows us to remove it?

services/tunnelbroker/src/Tools/AwsTools.cpp
19–28 ↗(On Diff #12491)

This has been moved to services/lib/src/DynamoDBTools.cpp

Thanks for D4013, I think it's much clearer now.

This revision is now accepted and ready to land.May 12 2022, 6:45 AM