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

add middlewares to fill the cache #337

Closed
wants to merge 5 commits into from
Closed

Conversation

arschles
Copy link
Member

@arschles arschles commented Jul 26, 2018

also adding a middleware to fill in the module and version names

cc/ @marwan-at-work - this could be an alternative or complement (not sure?) to the download protocol you introduced in #336

this makes progress toward #290 because the cache fill middleware can wrap the zip, mod and info endpoints to give them sync. cache filling "for free"

@arschles arschles added storage work to do on one or more of our storage systems proxy Work to do on the module proxy labels Jul 26, 2018
@codecov-io
Copy link

codecov-io commented Jul 26, 2018

Codecov Report

Merging #337 into master will increase coverage by 0.1%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##           master     #337     +/-   ##
=========================================
+ Coverage   37.64%   37.75%   +0.1%     
=========================================
  Files         102      102             
  Lines        2757     2757             
=========================================
+ Hits         1038     1041      +3     
+ Misses       1615     1613      -2     
+ Partials      104      103      -1
Impacted Files Coverage Δ
pkg/repo/github/commitinfo.go 76% <0%> (+12%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8ef9d7f...a59388e. Read the comment docs.

return err
}
defer ref.Clear()
version, err := ref.Read()
Copy link

Choose a reason for hiding this comment

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

Is this meant to escape this block? Currently it is never used besides the deferred zip close below.

Copy link
Member Author

Choose a reason for hiding this comment

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

good call - this is supposed to be versionInfo, err = ref.Read(). change incoming

lggr.SystemErr(err)
return err
}
c.Set("versionInfo", version)
Copy link

Choose a reason for hiding this comment

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

Is this meant to set the versionInfo param to the string version from 23?

Copy link
Member Author

Choose a reason for hiding this comment

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

this should set to versionInfo, thanks for catching this!

Copy link
Contributor

@marwan-at-work marwan-at-work left a comment

Choose a reason for hiding this comment

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

Personally I'm not a fan of overloading context values because it has no safety guarantees and it's hard to test.

I'd suggest either making the middleware's next function be type safe (similar to what we discussed in #328) or we just implement a download.Protocol that eliminates the need for a middleware in the first place.

Something like this

func (p *protocol) Info(ctx context.Context, mod, ver string) (RevInfo, error)  {
  v, err := p.storage.Get(ctx, mod, ver)
  if errors.ErrNotExist(err) {
    v, err = p.filleCache(ctx, mod, ver)
  }
  return v.Info, err
}

func (p *protocol) fillCache(ctx, mod, ver) (Version, error) {
  i, err := p.fetcher.Fetch(ctx, mod, ver)
  if err != nil { return {}, err }
  p.storage.Save(i) // handleErr
  return i, err
}

and so on.

Happy to hear your reasoning though, let me know!

}
c.Set("versionInfo", version)

if err := getterSaver.Save(
Copy link
Contributor

Choose a reason for hiding this comment

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

This means we always save back to Storage on every http call even if cache already existed no?

Copy link
Member Author

Choose a reason for hiding this comment

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

yup, that's a big bug on my part, thanks for catching


// ParamsMiddleware fetches module and version params from c and calls next with "value"
// and "version" strings in the context. Access them with c.Value("module") and c.Value("version")
func ParamsMiddleware(next buffalo.Handler) buffalo.Handler {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need middleware for this if we can just call path.GetAllParams from inside a handler?

Copy link
Contributor

Choose a reason for hiding this comment

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

PS. if it's the error handling part, paths.GetAllParams shouldn't really return an error. It can safely panic because that means we got something seriously screwed up in our http paths.

Copy link
Member Author

Choose a reason for hiding this comment

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

@marwan-at-work that's fair. I was trying to remove a bit of error handling code from all the handlers here. I'll move this into the cache fill middleware handler

@arschles
Copy link
Member Author

arschles commented Jul 27, 2018

@marwan-at-work RE your comment on overloading context - I was following the buffalo middleware docs here. I def understand the type-safety argument and normally I'd be for it, but I think it's a tough tradeoff in this case because we exchange a bit of "magic" (setting interface{} context values) for less code in the handlers.

Would you be ok with submitting just the download protocol bits from #336 in a new PR so we can get that in separately from the /list stuff in #336, and see how it looks in here?

EDIT: I see that #336 is almost ready to merge

@arschles
Copy link
Member Author

Closing in favor of #342

@arschles arschles closed this Jul 27, 2018
@arschles arschles deleted the sync branch July 27, 2018 21:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proxy Work to do on the module proxy storage work to do on one or more of our storage systems
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants