-
Notifications
You must be signed in to change notification settings - Fork 103
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
refactor(ecocredit)!: migrate core ecocredit msg_server to use ORM #723
Conversation
@@ -50,14 +54,13 @@ func NewIntegrationTestSuite(fixtureFactory testutil.FixtureFactory, paramSpace | |||
|
|||
func (s *IntegrationTestSuite) SetupSuite() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should consider refactoring all these separate integration test into smaller, bite sized unit tests, and then just have one big integration test. imo it makes more sense at these tests look more like unit tests than integration anyways
it's a bit confusing to figure my way around this code. the batch info test is broken and the case thats failing has a hard coded batch denom to search for. i'm not really even sure what the best approach to fixing that test would be other than obliterating the existing test structure to fit my needs..
should we create an issue to move these smaller tests into unit tests? @aaronc @ryanchristo @robert-zaremba thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. A lot of these tests are written like unit tests already. I think it makes sense to separate them out and to simply the integration tests in a separate issue. You should be able to trace the batch denom issue without obliterating the existing structure. Would be happy to take a look if you get stuck.
2178d73
to
8676847
Compare
@@ -4,7 +4,7 @@ package regen.ecocredit.basket.v1beta1; | |||
|
|||
import "regen/ecocredit/basket/v1beta1/types.proto"; | |||
|
|||
option go_package = "github.com/regen-network/regen-ledger/x/ecocredit/v1beta1"; | |||
option go_package = "github.com/regen-network/regen-ledger/x/ecocredit/basket/v1beta1"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code wasn't being generated for these packages, i assume they were being overwritten by core which gets written last? all code from these sub packages get generated now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great. Nice work! Still working through the review. A few comments to start.
if s == "" { | ||
s = "0" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we throw an error if the string is empty? I think it might be safer to require a value to be explicitly set rather than assuming an empty string should be 0
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i found a few places where were we would explicitly check for the empty string case and then set it to "0" anyway, so it felt like a good way to reduce that.
are there any specific cases where we'd prefer to error here instead of defaulting to 0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to handle "", no need to parse anything just return a zero value.
Seems like we'd check for "" elsewhere if we actually want a nullable case so I think this default is okay
// delete the old issuers | ||
if err = s.stateStore.ClassIssuerStore().DeleteBy(ctx, ecocreditv1beta1.ClassIssuerClassIdIssuerIndexKey{}.WithClassId(class.Name)); err != nil { | ||
return nil, err | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use Update
rather than deleting the old and inserting the new one by one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the primary key is made up of the classID+issuer_address, so it wouldn't work in this case. if it had a simple row ID primary key with class+issuer indexes, i could do that - i'm not sure on the benchmarks of either case though, could look into some metrics for ORM ops if we value it
Co-authored-by: Ryan Christoffersen <12519942+ryanchristo@users.noreply.github.com>
…k/regen-ledger into ty/696-eco_orm_core
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation generally looks good. A few things to clean-up. Some of them can be in follow-ups as they're related to existing design choices
projectID := req.ProjectId | ||
if projectID == "" { | ||
found := false | ||
for !found { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need a loop here? something seems not quite right here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was actually your suggestion in the original projects PR 😄 - #647 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to loop to avoid a clash but the way this loop is structured is just confusing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you have any suggestions to make it clearer? i had thought it was pretty straightforward but open to suggestions
2a7aac3
to
9bdcd8a
Compare
this PR is now more in line with the architecture used for #732. There's quite a lot of code in here, so I can opt to split this into chunks and submit multiple, smaller PR's. I've implemented the msg server and query servers for v1beta1 proto files with unit tests. It is not wired up to the existing msg_server yet, as that require moving around more things and making an already large diff even larger. Would appreciate any feedback/ideas on how to proceed from here! @aaronc @ryanchristo @clevinson :-) |
This pull request is being broken up into smaller pull requests. |
should we just close this then? |
Description
beginning of ecocredit ORM refactor
Closes: #696
Closes: #707
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...
!
to the type prefix if API or client breaking changeCHANGELOG.md
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...
!
in the type prefix if API or client breaking change