Skip to content
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

Closed
lleger opened this issue Apr 19, 2018 · 3 comments
Closed

Binary primary key #8

lleger opened this issue Apr 19, 2018 · 3 comments

Comments

@lleger
Copy link

lleger commented Apr 19, 2018

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?

@samsondav
Copy link
Owner

@lleger thanks for opening an issue!

Yes, the migration uses integer primary keys. Can I ask why you would prefer a UUID?

@lleger
Copy link
Author

lleger commented Apr 20, 2018

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.

@samsondav
Copy link
Owner

samsondav commented Apr 24, 2018

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants