-
Notifications
You must be signed in to change notification settings - Fork 127
Rename owners to controllers #423
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
Conversation
| } | ||
| ], | ||
| link: "bafyreighkvhf5ghi5hyeoain4y5p5zn5k6dyoazkjso3gnwbsqi7tk32ze" | ||
| link: "bafyreiago3pnhq2r7yy4osv7h7yrja7vfkuyzvdiloqnhsk64qcior6tn4" |
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.
This was the issue that was causing the test to fail. The test was finding this 'link' field was coming back with a value different than what it expected. I simply took what the test was actually finding and pasted it here into the expected slot. Not very good testing practices, as I didn't actually verify that this is the proper value that this field should really have. I'm not sure exactly how this field is calculated, but my guess is that it's derived from a hash of the data, and that buy changing "owners" to "controllers" I changed the resulting hash. Do you know how I would go about actually verifying that this is the proper expected value so that we know the test is actually testing the proper behavior and not just set to expect what it is outputting, regardless of whether that's correct?
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.
Yes this is expected to change given that it's the CID (hash + additional data) of the genesis content above. I think it's safe to assume that this hash is correct, but you can try to change the genesis content again to make sure that that does indeed change this CID.
In general in dag-jose the link property is a CID instance of the base64url encoded payload. Not sure why they are different in this test. Probably because this object is created by some mock.
You can learn more about dag-jose here:
https://github.com/ceramicnetwork/js-dag-jose
ipld/specs#269
oed
left a 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.
Looks good. I'll let @simonovic86 decide when to merge this as it's a breaking change and it would likely make sense to release together with many of your other tickets @stbrody since they are also breaking changes.
| } | ||
| ], | ||
| link: "bafyreighkvhf5ghi5hyeoain4y5p5zn5k6dyoazkjso3gnwbsqi7tk32ze" | ||
| link: "bafyreiago3pnhq2r7yy4osv7h7yrja7vfkuyzvdiloqnhsk64qcior6tn4" |
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.
Yes this is expected to change given that it's the CID (hash + additional data) of the genesis content above. I think it's safe to assume that this hash is correct, but you can try to change the genesis content again to make sure that that does indeed change this CID.
In general in dag-jose the link property is a CID instance of the base64url encoded payload. Not sure why they are different in this test. Probably because this object is created by some mock.
You can learn more about dag-jose here:
https://github.com/ceramicnetwork/js-dag-jose
ipld/specs#269
yep, I agree with @oed. It would make sense if we can put together all the breaking changes ( |
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.
LGTM! Let's put all breaking changes tweaks and renames under the same repo. It will be easier to handle merge conflicts, etc. Makes sense?
Just a note @stbrody the way of how we create branches now is:
feat/some-featureif it's a featurefix/some-fixif it's a bugchore/some-choreif it's a chore.
No description provided.