-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the structure of PostReaction #157
Labels
kind/enhancement
Enhance an already existing feature; no "New feature" to add
Milestone
Comments
RiccardoM
added
the
kind/enhancement
Enhance an already existing feature; no "New feature" to add
label
May 11, 2020
RiccardoM
changed the title
Improve the structure of
Improve the structure of PostReaction
May 11, 2020
PostReaction
The change you suggest is good and I think that, if we do this to help for a better integration with middle-layers like Djuno, 1GB will not change our lives. |
It's already another story for Desmos when there are 6m reactions 😄. Performance and data integrity is at higher priority than storage. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
Currently in order to represent a single post reaction, what we are doing is using this object:
This is used also inside the
GenesisData
to represent all the reactions that have been added to the different posts.Using this object from an outsider point of view, it is not enough in specific cases. Particularly, I've found some difficulties when handling it inside the genesis from within DJuno. Since the
Value
field can contain either the reaction shortocode or emoji value, it's hard to parse them and store them inside the database.Solution
In order to solve the above mentioned problem I propose a revisit of this data type, in order to extend it so that it includes both the shortcode and the value of the emoji:
Notes
I acknowledge that this approach comes with a con, which is the fact that emoji values and registered emojis will occupy a lot more storage than the current version due to the fact that their shortcode will be stored multiple times.
While this might be a problem, supposing we have all reactions with shortcodes that are 20 characters long (equivalent of 160 bytes, which is a very long shortcode to be honest), it would mean that in order to have a significant disk space change (1GB) we would have to have at least 6,250,000 reactions used. Personally I think that 1GB for 6 millions reactions is fair as long as that change allows for a better usage from the developer perspective.
The text was updated successfully, but these errors were encountered: