Closed devajmeireles closed 1 week ago
Hey, @freekmurze ! I'd like to know your opinion on this before I continue with the PR :D There doesn't seem to be any breaking changes, but I'd like your opinion on whether I should move forward because it's something interesting in your eyes.
@devajmeireles please feel free to continue with this PR. I'm happy to review it once it's ready :+1: Thank you!
@devajmeireles please feel free to continue with this PR. I'm happy to review it once it's ready 👍 Thank you!
Hey, @patinthehat ! Thanks for your feedback. I think the PR is ready for review. Feel free to review it and point out anything misaligned or incorrect so I can adjust it.
Hey, @patinthehat ! I applied all your suggestions. I also tried searching for UUID
(or variations, like: uuid
) in the docs, to write something special for someone who wants to use ULID instead of UUID, but the docs don't mention anything related to that, so I just updated the installation.md
docs with the new configuration value.
Hi @devajmeireles I'm sorry it took a while to come back on this PR. We had a little discussion in our team and agreed that we will not be merging the PR.
While we acknowledge the benefits of ULID we believe it's better to keep simplicity in mind and not offer too many options. Users can still extend the Media model to modify the current implementation.
Based on several studies and personal tests, we can prove the effectiveness of
ulid
columns instead ofuuid
when talking about a large volume of data.A package like this tends to persist a thousand of data in the database since all the media of an entire application is persisted in a table. Some public studies point to abstracts where ULID is advantageous in these cases.
A good read is here: https://medium.com/@sammaingi5/uuid-vs-ulid-how-ulid-improves-write-speeds-d16b23505458
This PR is an attempt to implement a configuration that allows ULID to be used instead of UUID.