json marshal / unmarshal for hashid#29
Merged
stereosteve merged 3 commits intomainfrom Apr 18, 2025
Merged
Conversation
50159c6 to
f6c7496
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Yesterday @schottra had mentioned using custom JSON marshal / unmarshal functions for playlist library... and it occurred to me we could experiment with that for hash ID encoding.
Might make sense to view the commits in series:
First one does developer apps which shows that for the vanilla case we don't have to define Full struct variants to override an ID column. In developer apps case, the min response is identical to full response, so we can also skip that step.
The second one uses
trashid.TrashIdforidfield on users... while keepinguser_idan int in the response (for your debugging pleasure!). This is a bit trickier as it gets into howsqlc.yamlfield mapping works... but not too bad.My main concern with this is that it is all up in the intersection of sqlc + golang + json in ways that might be confusing / surprising to devs. Like if we define a struct type in
jsonb_types.gofor a jsonb column... if you try to usetrashid.TrashIdin that struct it'll go badly because the JSON coming from the database will be a number buttrashid.TrashIdwill expect to decode a hashid... and it'll fail.We could probably define other type variants that just have
MarshalJSONand notUnmarshalJSON. Or we could add some code to try to handle this case inUnmarshalJSON.Maybe the move here is to expand this branch to use this custom type everywhere and see if it's overall good or bad.