This repository has been archived by the owner on Apr 24, 2023. It is now read-only.
Store entities (not UUIDs) in Liberator context #617
Labels
Comments
scrosby
pushed a commit
to scrosby/Cook
that referenced
this issue
May 31, 2018
It also used the list-jobs function referred to in the last commit. This refactor removes the use of list-jobs, cleans up the /jobs endpoint, and addresses part of twosigma#617. /jobs no longer propagates UUID's in the liberator context.
scrosby
pushed a commit
to scrosby/Cook
that referenced
this issue
Jun 4, 2018
…ext for /jobs endpoint. Avoids the same from-uuid to-uuid round-trip in the /jobs endpoint. Stored in ::jobs-entities.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We're currently caching the UUIDs of our jobs/instances/groups in the Liberator context when processing the decision handlers for our REST endpoints. That choice results in a lot of repeated UUID→Entity conversions, which probably aren't too expensive, but likely aren't negligible either.
We could eliminate a lot of duplicate computation in the handlers by storing datomic entities (rather than UUIDs) in the context. I'm not sure if this will result in a measurable speedup, but it seems worth exploring. Even if there's no speed improvement, I think the code complexity reduction would be a clear win.
The text was updated successfully, but these errors were encountered: