-
Notifications
You must be signed in to change notification settings - Fork 0
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(providerindex): accept multiple legacy options #86
base: fix/claim-fallback-cid
Are you sure you want to change the base?
refactor(providerindex): accept multiple legacy options #86
Conversation
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.
Incredible debugging!
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.
that's an interesting corner case! Implementation looks good, I left some minor comments.
} | ||
|
||
// LegacyClaimsStore allows finding claims on a legacy store | ||
type LegacyClaimsStore struct { | ||
contentToClaims ContentToClaimsMapper | ||
contentToClaims []ContentToClaimsMapper |
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.
np: I'd rename this to mappers
or something like that, now that there may be several of them
return nil, nil | ||
} | ||
|
||
func (ls LegacyClaimsStore) findOne(ctx context.Context, contentHash multihash.Multihash, targetClaims []multicodec.Code, mapper ContentToClaimsMapper) ([]model.ProviderResult, error) { |
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 is this function called findOne
? maybe it had a different goal before?
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's checking one mapper when the function above checks many
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.
got it. The very first thing that came to my mind was "find one result". I guess I'm too used to datastore APIs :)
for _, mapper := range ls.contentToClaims { | ||
claims, err := ls.findOne(ctx, contentHash, targetClaims, mapper) | ||
if err != nil { | ||
return nil, err | ||
} | ||
if len(claims) > 0 { | ||
return claims, nil | ||
} | ||
} |
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 results of this logic will depend on the order the mappers are provided in the slice. The results being returned will be the ones given by the first mapper returning any result.
Not saying it's wrong, but it may be worth stating it clearly somewhere (in the comment for NewLegacyClaimsStore
, maybe?).
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 that's the goal, but it's absolutely worst stating
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.
maybe add a test for correct filtering of claims according to targetClaims
?
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.
yea
Co-authored-by: Vicente Olmedo <[email protected]>
Co-authored-by: Vicente Olmedo <[email protected]>
Goals
Get a full roundtrip to work with freeway -- these are all the additional changes required
Implementation
For Discussion
Still need to add some new test cases for the legacy claims finders now that it uses multiple mappers & handles filtering