I don't any detail to add here; I just heard Siggie mention this at a meeting, that there is a query param which I think is a JSON serialization of everything in storage, which would be insanely big. Sometimes it can get too big.
Siggie tried to compress, but didn't work.
Questions
What happens when it "gets too big"?
I don't know what that means, whether (a) it exceeds the maximum URL length allowed by the browser, if such a thing exists (I see on the internet that the official HTTP spec states 2,048 should be the maximum), or (b) it crashes the browser.
Why do we need this?
Is this so that the user can easily come back to the state they left off at, regardless of the machine?
Why not just leave such things in local storage?
The advantage is that the URL could work for anyone, or the same user on multiple machines, but I don't see users really asking for that.
Possible solutions
1. Use a hash, and cache it in the database
Concerns: Eventually we should clear the cache if unused for a long time. So we should implement some kind of LRU cache. A google search shows that there are some ways to do this in Postgres.
Overview
I don't any detail to add here; I just heard Siggie mention this at a meeting, that there is a query param which I think is a JSON serialization of everything in storage, which would be insanely big. Sometimes it can get too big.
Siggie tried to compress, but didn't work.
Questions
Possible solutions
1. Use a hash, and cache it in the database
Concerns: Eventually we should clear the cache if unused for a long time. So we should implement some kind of LRU cache. A google search shows that there are some ways to do this in Postgres.