Closed cyrildewit closed 2 years ago
I've found out that using HashIDs are case sensitive. We have an option to disable this, but this will cut the number of uses in half. So we are trying to find a way how to solve this.
We have found out the following regarding Hash ids;
varbinary
or binary.
How to implement this can be found at https://laracasts.com/discuss/channels/eloquent/varbinary-equivalent-in-eloquentAsked for advice from one of my colleagues. He will advise UUID since this is already implemented into Laravel which makes it easier for the application to understand and use.
@Hoopless Although it's good to think about what is easier to implement within Laravel, I think it's still interessant to research and learn more about HashID's.
I don't think we have to store the HashId in the database, but only the ID. That's the whole purpose of this right 😂 .
So: /users/asfasdf asfasdf => 203 SELECT * FROM users WHERE id = 203
Hey @cyrildewit, Yes agreed. However, I wanted to note how my (work) colleagues thought about it. I am sure we will implement this feature. But indeed, in the database. I will pick the ticket (https://github.com/KA-Huis/space-management/issues/67) up and will change the information in the ticket itself.
Hey @cyrildewit, Yes agreed. However, I wanted to note how my (work) colleagues thought about it. I am sure we will implement this feature. But indeed, in the database. I will pick the ticket (https://github.com/KA-Huis/space-management/issues/67) up and will change the information in the ticket itself.
@Hoopless I understand where you comment came from. I just reacted with what thought popped up in my mind. I realised something stupid.
Analysis
Resources
Advice
After discussing this ticket with @Hoopless and @MiKessels, we've decided to use the standard ID. UUID and HashID will require some extra research to properly implement it.