rails / solid_cache

A database-backed ActiveSupport::Cache::Store
MIT License
890 stars 63 forks source link

Rails Migration ignores Rails.application.config.generators primary_key_type: :uuid #98

Closed freibuis closed 1 year ago

freibuis commented 1 year ago

Might be a little nitpick but when using some initializer like

Rails.application.config.generators do |g|
  g.orm :active_record, primary_key_type: :uuid
end

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|

rafaelsales commented 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?

skatkov commented 1 year ago

@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.

freibuis commented 1 year ago

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