Skip to content
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

feat(orm)!: return ormerrors.NotFound for Get methods in codegen #11113

Merged
merged 6 commits into from
Feb 4, 2022

Conversation

aaronc
Copy link
Member

@aaronc aaronc commented Feb 3, 2022

Description

I was talking with @technicallyty and we agreed that returning an error value when an entity is not found is the common golang idiom. What do you think @fdymylja ?

You can see how this looks in practice in module_test.go. I'm not actually sure this makes the code more succinct or the orm any easier to use. But maybe in certain cases yes.


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

Copy link
Member

@tac0turtle tac0turtle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

error here makes sense. Seems easier to handle too

@codecov
Copy link

codecov bot commented Feb 3, 2022

Codecov Report

Merging #11113 (60b4a45) into master (b9c7fd1) will increase coverage by 0.16%.
The diff coverage is 34.42%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #11113      +/-   ##
==========================================
+ Coverage   65.77%   65.93%   +0.16%     
==========================================
  Files         649      698      +49     
  Lines       66602    70810    +4208     
==========================================
+ Hits        43805    46692    +2887     
- Misses      20280    21253     +973     
- Partials     2517     2865     +348     
Impacted Files Coverage Δ
codec/proto_codec.go 62.22% <21.42%> (-12.12%) ⬇️
client/grpc_query.go 30.95% <21.73%> (-5.56%) ⬇️
baseapp/grpcrouter.go 85.48% <100.00%> (-0.46%) ⬇️
baseapp/grpcrouter_helpers.go 25.00% <100.00%> (-4.63%) ⬇️
server/grpc/server.go 67.64% <100.00%> (+3.13%) ⬆️
orm/encoding/ormfield/enum.go 80.00% <0.00%> (ø)
orm/model/ormdb/file.go 57.14% <0.00%> (ø)
orm/model/ormtable/build.go 77.43% <0.00%> (ø)
orm/model/ormtable/singleton.go 46.96% <0.00%> (ø)
orm/internal/fieldnames/fieldnames.go 100.00% <0.00%> (ø)
... and 46 more

@aaronc
Copy link
Member Author

aaronc commented Feb 3, 2022

What if we returned grpc status NotFound? That would be most convenient in query servers.

We could make our errors module compatible with grpc codes possibly

@aaronc
Copy link
Member Author

aaronc commented Feb 3, 2022

Added a helper ormerrors.IsNotFound() in case we want to change things later... I do think there's value in considering grpc errors here

Copy link
Contributor

@technicallyty technicallyty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙏🏻 thanks!

Copy link
Contributor

@fdymylja fdymylja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a helper ormerrors.IsNotFound() in case we want to change things later... I do think there's value in considering grpc errors here

+1, I've been advocating a lot for sdkerrors to implement GRPCStatus().
+1 also for returning errors rather than a boolean.

I think in the end orm errors can be of three categories (when you're interacting with it):

  • NotFound for Delete/Update/List/Read (grpcstatus.NotFound)
  • AlreadyExists for Create (grpcstatus.AlreadyExists)
  • BadRequest for everything bad in the request format (invalid type, invalid indexes query, etc) (grpcstatus.InvalidArgument)

@aaronc
Copy link
Member Author

aaronc commented Feb 4, 2022

Is GRPCStatus() part of the public API? Seems like an implementation detail I'm not sure is safe to depend on

@fdymylja
Copy link
Contributor

fdymylja commented Feb 4, 2022

Is GRPCStatus() part of the public API? Seems like an implementation detail I'm not sure is safe to depend on

It is not part of the public API... We could have only sdk/error implement it. So if the GRPCStatus interface changes we can follow it by modifying one type, not sure how developers would signal what status an error represents.

@github-actions github-actions bot added the C:CLI label Feb 4, 2022
@aaronc aaronc added A:automerge Automatically merge PR once all prerequisites pass. and removed C:CLI A:automerge Automatically merge PR once all prerequisites pass. labels Feb 4, 2022
@aaronc aaronc added the A:automerge Automatically merge PR once all prerequisites pass. label Feb 4, 2022
@aaronc
Copy link
Member Author

aaronc commented Feb 4, 2022

Is GRPCStatus() part of the public API? Seems like an implementation detail I'm not sure is safe to depend on

It is not part of the public API... We could have only sdk/error implement it. So if the GRPCStatus interface changes we can follow it by modifying one type, not sure how developers would signal what status an error represents.

errors.NewWithCode(codespace, 1, code.NotFound, "not found")

We can either do that or use grpc status directly. What do you think?

@mergify mergify bot merged commit 8110576 into master Feb 4, 2022
@mergify mergify bot deleted the aaronc/orm-get-error branch February 4, 2022 16:07
@aaronc aaronc mentioned this pull request Feb 25, 2022
19 tasks
mergify bot pushed a commit that referenced this pull request Feb 25, 2022
## Description

Follow-up to #11113 (review).

This PR also makes `New` an alias of `Register` as some packages are using `New` as if it were `Register` but are not actually registering their error codes.



---

### Author Checklist

*All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.*

I have...

- [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] added `!` to the type prefix if API or client breaking change
- [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [ ] provided a link to the relevant issue or specification
- [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [ ] added a changelog entry to `CHANGELOG.md`
- [ ] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [ ] updated the relevant documentation or specification
- [ ] reviewed "Files changed" and left comments if necessary
- [ ] confirmed all CI checks have passed

### Reviewers Checklist

*All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.*

I have...

- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed `!` in the type prefix if API or client breaking change
- [ ] confirmed all author checklist items have been addressed 
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass. C:orm
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants