Conversation
|
@gbaz I'm still unclear on how to initialise the Map and keep it updated. Shall we pass it in a TVar, and update it in the upload endpoint? Again, I'm very unfamiliar with the usual patterns of this project, but I'm willing to learn! :) |
|
@gbaz I'd be grateful if you could help me put the last pieces of the puzzle together, when time permits. :) |
|
ok i think i see the confusion. what i mean is why do we need any acid-state for any of this? can't we just compute it on the fly? before i had suggested a better way to cache, but i don't think we need to cache it either. hitting these endpoints should be rare, and all the data is available to query elsewhere. I think we shouldn't need acid-state specific to back this json endpoint at all, much less to migrate it. |
|
@gbaz ok then I must be mis-understanding the role of |
|
i'm saying don't have a cache. there's no need to cache the data fetch it on demand. |
dc8abe7 to
924e889
Compare
924e889 to
31b0e67
Compare
|
@gbaz I tried it locally and the results are good. While pairing on this with @edmundnoble we noticed that the package description cache does not seem to be so useful, now that we always resolve pkgId, but maybe I am mistaken regarding the architecture. |
|
by package description cache you mean the |
|
@gbaz ok! I will probably do it in another PR after this one is merged then. :-) |
|
Wouldn't that subsume this? |
|
@gbaz yes indeed. See my last commits. I removed the cache interface for package descriptions as well, if that' ok with you. If not I can revert that particular commit without problems. |
|
Thanks for the work. I went ahead and cleared out the state cache entirely to finish the job. |
|
@gbaz Cheers. :) I wasn't sure how deep we could clean this up and not get bitten in prod. :) |
Follow-up of #1375 to use a Map rather than storing usernames in acid-state.
Since the datatype used for storage no longer reflects the shape of the API payload, I made a separate DTO for it.