|
You might find it worthwhile figuring out why it was failing via a segfault on that exec line, as opposed to failing in a way that would have given you more information on what the actual failure was. Your error-handling code would be better described as "error-ignoring".
|
#
¿
Feb 26, 2018 06:39
|
|
|
|
| # ¿ May 11, 2024 22:30 |
|
|
Pollyanna posted:How are you expected to keep protobuf definitions and compiled files up to date? Just constantly ping a GitHub repo until the file changes or something? That sounds dangerous. That's the best part about protobufs - if you do them right, you don't have to. As long as your protobuf only changes in particular ways, servers and clients can keep using the definitions they were originally compiled with and continue to work correctly, even when the thing they're talking to is using updated definitions. Can you give an example of a situation that you're concerned about?
|
|
#
¿
Sep 13, 2018 14:47
|
|
|
Pollyanna posted:We have some enums (a list of insurance agencies) that get updated with new entries e.g. a new “FooGroup Inc.” with id 180. Our old protobuf does not have that entry, so it can’t map 180 to the symbol “FooGroup Inc.”, and therefore bugs out because our “hey we can’t translate this symbol to a display string” exception handler logs “can’t translate symbol 180” instead of “can’t translate symbol FooGroup Inc.”. We need to know it’s symbol instead of just an integer so we know what entry we need to add to our translation dictionary. Generally speaking, if you're adding enum values, you should be able to sensibly handle the case where a client sees an enum value that it doesn't know about. Even if you perfectly solved your current problem, you'd still have a fundamentally similar issue when the client just happens to be out-of-date. For example, one option might be to lose the enums, and instead just use an opaque key (or perhaps just an integer key) to identify insurance agencies. Then, have your server expose an rpc that returns the information for the insurance agency with the given key. That way users don't need an entirely new client build every time you add an insurance agency, aren't working with outdated information if agency info changes, etc. -- Your exact problem also seems like more of a process issue. Wouldn't you update your translation dictionary when you add a new insurance agency (i.e. at the same time you add it to the enum)? As opposed to waiting until the first time someone actually uses that particular value, and then has to put up with untranslated strings until you've finished fixing it.
|
|
#
¿
Sep 13, 2018 16:45
|
|
|
For what it's worth, it's not actually that hard to build backwards-compatible apis, all you need to do is put in a tiny little bit of thought at the right time. I have no earthly idea why you'd go to all the effort to create an entirely different server for every little feature you want to ship, commit to maintaining parallel API surfaces for some amount of time, and then eventually say "gently caress you, update or your app stops working" when you decide it's finally time to turn down something. That's more work than just building your feature in a backwards-compatible way, in order to create a worse user experience!
|
|
#
¿
Sep 14, 2018 16:20
|
|
|
that's okay I'll just make them all interface{}
|
|
#
¿
Apr 11, 2023 02:15
|
|