Closed freibuis closed 1 year ago
@freibuis the gem relies on the id being an ordered key: https://github.com/rails/solid_cache/blob/main/app/models/solid_cache/entry.rb#L63
I have a hard time seeing the benefit of following the standard primary_key_type
of a rails application. That's most often used as a convenient way to ensure that most of your models use UUID in scenarios where you don't want to expose an enumerated id. Would there ever be a case where ids from this table would be exposed?
@rafaelsales makes a good point that UUID v4 might break functionality and is generally not a great idea for performance reasons.
But UUID v7 is sequential. While use of v7 is not that common these days, in future this might be a valid feature request.
the main reason I was thinking of was optional consistency. I did get it working after monkey patching and creating a million+ cache records. it had some really really really really bad performance... (did I say really bad!)
I take back this ticket. maybe UUID v7 might be a worth looking into definitely in the future
Might be a little nitpick but when using some initializer like
the doing the plain solid-cache install, the migration file does not include :uuid as the key.
simple workaround
create_table :solid_cache_entries, id: :uuid do |t|