Shrink metadata size #287
Description
I recently had a stack of 17 PRs which was generating GraphQL queries exceeding 600KB in size. 17 is not a ridiculous number of PRs to stack, so GHerrit should aim to gracefully support this use case. We were able to partially address it with #284, but we should also generally attempt to shrink the sizes of PR bodies.
The most obvious change that comes to mind is shrinking the gherrit-pr-id field, which is currently a 42-character hex string. A few thoughts:
Base32 encoding should shrink this by ~20% (Encode PR IDs as base32 #290)- Use lower-case letters in base32 encoding – upper-case letters look weird (e.g.
GI7PO52I2CB3PQQC425CDLSKBPLNCSPM3vsGi7po52i2cb3pqqc425cdlskbplncspm3) - Base62 encoding should shrink this to ~28 characters (base64 is dangerous because it includes non-alphanumeric characters)
- Base62 is still risky because it may cause issues on non-case-sensitive filesystems. If we decide to adopt it, we'll need to think carefully about how to work around these issues (or at least calculate the likelihood of collision given the current ID generation scheme)
- Currently, we use randomness alone to guarantee uniqueness. There may be other ways to guarantee uniqueness that don't require as large of a sample space.