The plan is for Active Storage to use a three-level configuration for 
multiple services, like Active Record with multiple databases:

primary:

  production:

    service: S3

    # ...

  

  development:

    service: Disk

    # ...



avatars:

  production:

    service: S3

    public: true

    # ...



  development:

    service: Disk

    public: true

    # ...



On Thu, Feb 13, 2020 at 12:49 AM "gmail.com" <pva...@gmail.com> wrote:

“Some of the changes to ActiveStorage for Rails 6.1 have been focused on 
enabling finer-grained configuration around storage backends for specific 
Attachments/Blobs.  This seems like a generally fantastic feature, and the 
changes around it seem well-considered.

I stumbled on to this change as I was implementing another feature in our own 
project that seems to be at odds, however.  In order to have representative 
data in our development and staging environments – and verify that our backups 
are functional – we will regularly restore production backups to those 
environments.  Today, with different service configurations in development and 
staging, ActiveStorage resource loads simply fail.  (In an ideal world, we 
would use a FallbackService to delegate reads to one or more read-only 
services.)  



If the database records for Blobs also name the service they're stored in, that 
simultaneously solves the issue of failing loads (*assuming we have access to 
the configured production Service) and creates an issue whereby updates in 
development are capable of writing back to the production Service.  This issue 
ends up being particularly serious for when Blobs are being replaced or 
destroyed, as it can lead to production data being destroyed.  (We also can't 
implement a FallbackService as described above, as the configured service is 
only ever used when creating new Blobs.)



As I suspect that loading production data in non-production environments is not 
an uncommon practice, this seems risky.

• Is there a planned solution for this that we can document?

• How do we communicate the error case where the Blob's `service_name` cannot 
be accessed? (e.g. production is backed by the FileService, or configured by 
ENV variables that only exist on the production servers)

• Are there safety measures we can put in place to avoid destroying non-local 
data?









-- 



You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.



To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.



To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/3219d55d-46fe-4b56-98a5-56aaa3141597%40googlegroups.com.”

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-core/c5bc5d655c714e30d76a7e9a5cf6354376f50856%40hey.com.

Reply via email to