-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Think about ReadFrom/WriteToV2
one more time
#532
Comments
normally conversion to and from message to SDK entities should be done in exactly one place: https://pkg.go.dev/github.com/nspcc-dev/neofs-sdk-go/client and https://pkg.go.dev/github.com/nspcc-dev/[email protected]/pkg/network/transport respectively. V2-converters accidentally went beyond these two spaces of the system, so you are experiencing a headache
|
It does not matter if I need to use it in a single package or in a dozen packages, if I write tests, or if I am a regular SDK user. I just do it sometimes. The same way I encode cID and oID and maybe some other things that I forget about now. I just need more lines of (boilerplate) code for no reason (usually).
How can this help me? |
@carpawell, u've not described the exact problem yet in form: i want this but the only way is to cast into v2. If u have the case, report it if u have some useful helpers, just propose it in PR or create an enhancement issue |
Why do we need cases for exported methods in the "SDK" repo? We already have them (methods) and we are not gonna delete them. Why do I need this? Why this file has to have
The same way I have to encode/decode addresses, IDs, etc. Why? That is not about V2 only.
We are discussing such an issue right now. |
|
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 3. Test binaries/JSONs/signatures that followed the erroneous behavior of p.2 are fixed. 4. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. NOTE: `client` package is going to be changed the same way in the following commits. NOTE 2: some tests panic due to protobuf namespace conflict, which will be fixed automatically after the move is complete. Closes #214. Refs #226. Refs #532. Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Continues 8a26264 and finalizes deprecation of `neofs-api-go/v2` module in favor of `proto/` packages. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Signed-off-by: Leonard Lyubich <[email protected]>
Continues 8a26264 and finalizes deprecation of `neofs-api-go/v2` module in favor of `proto/` packages. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Signed-off-by: Leonard Lyubich <[email protected]>
Continues 8a26264 and finalizes deprecation of `neofs-api-go/v2` module in favor of `proto/` packages. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 3. Test binaries/JSONs/signatures that followed the erroneous behavior of p.2 are fixed. 4. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. NOTE: `client` package is going to be changed the same way in the following commits. NOTE 2: some tests panic due to protobuf namespace conflict, which will be fixed automatically after the move is complete. Closes #214. Refs #226. Refs #532. Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Continues 8a26264 and finalizes deprecation of `neofs-api-go/v2` module in favor of `proto/` packages. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Signed-off-by: Leonard Lyubich <[email protected]>
Problem
With
ReadFromV2
it mostly always required more lines of code to achieve the same thing withToV2
andFromV2
that allocate structs inside. We can think about some helpers placed near the methods.Context
Updating SDK in some old code or writing a new code can be annoying with these totally necessary lines (when there is no need to reuse struct b/w reading or writing protocol conversions). This approach was presented in #170 and we had some long discussions, it was not an easy change.
The text was updated successfully, but these errors were encountered: