Rodauth account related tables use UUID; should I be worried?

[Samuelodan]

So, my Rails app was already set to use UUID as the default ID type and I didn't realize that this affected the CreateRodauth migration that created tables like user_login_change_keys, setting them to use UUID for id.
I noticed today and now I wonder if I should go through the hassle of converting the three tables to use BigInt or just let them (and future Rodauth tables) continue to use UUID.

Will there any significant performance penalty?

[janko]

I don't think there would be any performance penalty for using UUIDs, they should work just as well as integers. There might be some general caveats regarding UUIDs, which I don't know as I didn't have much experience with them.

[Samuelodan]

Alright then. Thanks so much. I was a bit worried there.
On a side note, it seems like Sequel handles generating UUIDs pretty well out the box unlike ActiveRecord which kinda required me to use a function provided by the pgcrypto extension.

[Samuelodan]

Oh, I just found a downside to using UUID. The app throws this error if this kind of key, "12_QMgg7l5aSTU1di4T2UVu_NMtn3Td_-U1sQzp4uZ96iM", is passed as a param in a request like change-login and reset-password.

This is the error:

Started POST "/v1/auth/reset-password" for 127.0.0.1 at 2023-09-22 21:51:00 +0100
Processing by RodauthApp#call as */*
  Parameters: {"key"=>"12_QMgg7l5aSTU1di4T2UVu_NMtn3Td_-U1sQzp4uZ96iM", "password"=>"[FILTERED]", "password-confirm"=>"[FILTERED]"}
  Sequel (14.3ms)  DELETE FROM "user_password_reset_keys" WHERE (("id" = '12') AND (CURRENT_TIMESTAMP > "deadline"))
  ↳ app/misc/rodauth_app.rb:9:in `block in <class:RodauthApp>'
Completed 500 Internal Server Error in 26ms (ActiveRecord: 14.3ms | Allocations: 1290)

Sequel::DatabaseError (PG::InvalidTextRepresentation: ERROR:  invalid input syntax for type uuid: "12"
LINE 1: ...TE FROM "user_password_reset_keys" WHERE (("id" = '12') AND ...
                                                             ^
):

[Samuelodan]

Oh Hi @reczy,
Yeah, my migration looks just like yours with id: false and t.uuid :id, primary_keys: true for those tables.
The rest of my Rails tables use UUIDs too though, so I may not have to remove the dashes, but that's an interesting approach. Did you run into any issues with that?

Also, could you try sending this key 12_QMgg7l5aSTU1di4T2UVu_NMtn3Td_-U1sQzp4uZ96iM in your reset-password request? I'd like to see if it returns the same 500 response I get. It may not be a big deal, but it kinda bothers me and I'm already writing a migration to:

• drop the primary key constraint
• change the id column type to BigInt, and
• add a primary key constraint on that column.

Thanks for sharing your set up, Mike.

[reczy]

Ah, the dashes are just personal preference. It's pretty seamless, I just created a custom type:

# frozen_string_literal: true

class DashlessUUIDType < ActiveRecord::Type::Value
  # https://github.com/rails/rails/blob/main/activemodel/lib/active_model/type/value.rb
  # https://github.com/rails/rails/blob/main/activerecord/lib/active_record/connection_adapters/postgresql/oid/uuid.rb

  ACCEPTABLE_DASHLESS_UUID = /\A\h{32}\z/

  private

  def cast_value(value)
    casted = value.to_s.delete('-')
    casted if casted.match?(ACCEPTABLE_DASHLESS_UUID)
  end
end

Then in my models I can use eg:
attribute :id, DashlessUUIDType.new, default: -> { gen_uuid }
or
attribute :user_id, DashlessUUIDType.new

(I made a custom model concern to automatically loop through the attribute names and apply dashless to all uuid types so I don't have to do the above for every id and foreign key uuid field in every model).

I think that's all there was to it. Then, rails just takes care of everything automatically. FWIW, I use postgres.

---

[Samuelodan]

I think that's all there was to it. Then, rails just takes care of everything automatically. FWIW, I use postgres.

I see. Your implementation looks pretty neat, haha!

Regarding the error though, I've decided to leave it be cos I just discovered that the foreign key constraint on those Rodauth tables are set on the id column, so the column must match the User (or Account) model which was set up to use UUID in the first place.

I also noticed the keys in the email start with user id which is separated from the rest of the key by an underscore. This explains why it tried looking for a user with the id of 12 with that key I asked you to try; It tried looking up the integer in a UUID column.

I wouldn't have realized [this soon] if it weren't for our conversation.
Thanks once again, @reczy

[reczy]

Happy to help!

I know you're first question above related to performance. One consideration is the type of uuids you use:

https://www.2ndquadrant.com/en/blog/sequential-uuid-generators/
https://twitter.com/hnasr/status/1657569218609684480
https://brandur.org/nanoglyphs/026-ids

[Samuelodan]

Ah, these articles made for a really insightful read. Indexes and WAL appear to be a much more significant concern than uniqueness, especially since the proposed UUID alternatives are practically unique in their own right.
I'll share them with my team members so we can consider some adjustments.
Thanks 🙌🏼