-
Notifications
You must be signed in to change notification settings - Fork 49
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
Binary primary key #8
Comments
@lleger thanks for opening an issue! Yes, the migration uses integer primary keys. Can I ask why you would prefer a UUID? |
We use UUIDs as primary keys by default, so it would be nice to have all of the tables in the database use them consistently. If we add Rihanna, she would be the only table with a non-UUID primary key. |
It is not currently possible to customise the primary key in Rihanna. I'm not sure I see any clear benefit to having the ID be a UUID other than consistency for consistency's sake in your case. It would come at a cost of some extra code complexity (and an extremely tiny performance hit) and would also interfere with the default sorting order - Rihanna finds the oldest job by sorting by (id, enqueued_at). Unless there is some clear reason to do so I think I'd have to say I won't be able to support this. You are welcome to fork the library and modify it yourself though :) |
It looks like the migration is hard-coded to use an integer primary key. Is it possible to use a binary, such as PG's built-in support for UUID primary keys?
The text was updated successfully, but these errors were encountered: