[Suggestion] Primary keys in voyager migrations

[ptr2null]

I really like this admin package, but why bigInteger? in tables?

I'd had to change something in the user-table of laravel and changed the primary key to smallIncrements. While migration with Laravels artisan, it threw an error and I've narrowed it down that a foreign key to the pk of the user table was typed as bigInteger.

I don't want to discuss any performance wars about it, which is bullsh** nonetheless. However actually I was baffled that the primary keys in all of voyagers tables have at least the size of an normal integer - 32 bit. For roles table even 64-bit! Seriously? Who in this world makes 18.4 quintillion roles (!) in production?
There are use cases which need more than a 32-bit integer, even more than 64-bit. But not for security roles.

Thus I had to change those to realistic types. Why?
Programmers should use what is needed and not using the maximum for everything. IMO it is a lazy attitude and leads to bad code. That those big numbers were used just for the sake of simplicity is not an argument in the programming world.

I would strongly suggest to change these types. I can pull the changes if you want to review it.

[emptynick]

Simple answer: because Laravel did it.
We had to adapt a few migrations because the roles pivot-table references user-id.
It would simply fail when installing Voyager.
If you want to change it, you can.
Laravel allows you to override package-migrations by simply copying them into database/migrations (keeping the filename)

[fletch3555]

Everything that @emptynick said.

Also, I would caution you to watch your tone. I understand the frustration, but lashing out at devs that do this for the community (and receive no compensation) is a very good way to make us all want to quit and kill the project entirely. You don't have to agree with every decision we make, but I strongly urge you to calmly seek understanding before letting emotion take over. 99+% of the time, there will be a completely logical reason behind that decision, and it's not infrequently out of our control.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you have further questions please ask in our Slack group.