Confusing ephemeral behavior with has_uploadcare_file accessor

[Jack Christensen]

It appears that the accessor method generated by has_uploadcare_file creates a new Uploadcare::Rails::File instance every time it is called.

This means that calling load_data doesn't appear to have any effect unless the result is manually stored.

Given:

class Company < ApplicationRecord
  ...
  has_uploadcare_file :uploadcare_logo
  ...
end

This behavior at the console is surprising:

[23] pry(main)> company.uploadcare_logo
=> #<Uploadcare::Rails::File uuid="b170e951-xxxx-xxxx-xxxxxxxxxxxx", operations=[]>
[24] pry(main)> company.uploadcare_logo.loaded?
=> false
[25] pry(main)> company.uploadcare_logo.load_data
=> #<Uploadcare::Rails::File uuid="b170e951-xxxx-xxxx-xxxxxxxxxxxx", operations=[], ... mime_type="image/jpeg", ...>
[26] pry(main)> company.uploadcare_logo.loaded?
=> false
[27] pry(main)> a = company.uploadcare_logo
=> #<Uploadcare::Rails::File uuid="b170e951-xxxx-xxxx-xxxxxxxxxxxx", operations=[]>
[28] pry(main)> a.load_data
=> #<Uploadcare::Rails::File uuid="b170e951-xxxx-xxxx-xxxxxxxxxxxx", operations=[], ... mime_type="image/jpeg", ...>
[29] pry(main)> a.loaded?
=> true
[30] pry(main)> a.mime_type
=> "image/jpeg"
[31] pry(main)> company.uploadcare_logo.mime_type
=> nil

A quick look at the source reveals that build_file tries a lookup with Rails.cache, but it doesn't look like the file ever gets saved to the cache in the normal read case. Of course, that is beside the point of whether it makes sense for the accessor to create a new object every time, even if some of it is cached.

[dmitrijivanchenko]

@jackc, we have released a new 2.0.0 version. We have removed caching objects behavior in v2 to cache only object attributes. Thanks for the issue 👍

❗ See migration guide, v2 is not backward compatible with v1