aboutsummaryrefslogtreecommitdiffstats
path: root/activestorage/README.md
diff options
context:
space:
mode:
authorXavier Noria <fxn@hashref.com>2017-08-15 18:48:19 +0200
committerXavier Noria <fxn@hashref.com>2017-08-15 18:50:46 +0200
commitae87217382a4f1f2bdfcdcb8ca6d486ec96e8d6c (patch)
tree1f64e60447883ad3a112b3b7425d5ab28bbecdf2 /activestorage/README.md
parent76ee15f04f2455c225b11466e9d4e5c32667b148 (diff)
downloadrails-ae87217382a4f1f2bdfcdcb8ca6d486ec96e8d6c.tar.gz
rails-ae87217382a4f1f2bdfcdcb8ca6d486ec96e8d6c.tar.bz2
rails-ae87217382a4f1f2bdfcdcb8ca6d486ec96e8d6c.zip
minor tweaks in Active Storage after a walkthrough
Diffstat (limited to 'activestorage/README.md')
-rw-r--r--activestorage/README.md29
1 files changed, 22 insertions, 7 deletions
diff --git a/activestorage/README.md b/activestorage/README.md
index d4ffe0c484..17d98978bb 100644
--- a/activestorage/README.md
+++ b/activestorage/README.md
@@ -1,17 +1,16 @@
# Active Storage
-Active Storage makes it simple to upload and reference files in cloud services, like Amazon S3, Google Cloud Storage or Microsoft Azure Storage and attach those files to Active Records. It also provides a disk service for testing or local deployments, but the focus is on cloud storage.
+Active Storage makes it simple to upload and reference files in cloud services like Amazon S3, Google Cloud Storage, or Microsoft Azure Storage, and attach those files to Active Records. Supports having one main service and mirrors in other services for redundancy. It also provides a disk service for testing or local deployments, but the focus is on cloud storage.
Files can be uploaded from the server to the cloud or directly from the client to the cloud.
-Image files can further more be transformed using on-demand variants for quality, aspect ratio, size, or any other
-MiniMagick supported transformation.
+Image files can furthermore be transformed using on-demand variants for quality, aspect ratio, size, or any other [MiniMagick](https://github.com/minimagick/minimagick) supported transformation.
## Compared to other storage solutions
-A key difference to how Active Storage works compared to other attachment solutions in Rails is through the use of built-in [Blob](https://github.com/rails/rails/blob/master/activestorage/app/models/active_storage/blob.rb) and [Attachment](https://github.com/rails/rails/blob/master/activestorage/app/models/active_storage/attachment.rb) models (backed by Active Record). This means existing application models do not need to be modified with additional columns to associate with files. Active Storage uses polymorphic associations via the join model of `Attachment`, which then connects to the actual `Blob`.
+A key difference to how Active Storage works compared to other attachment solutions in Rails is through the use of built-in [Blob](https://github.com/rails/rails/blob/master/activestorage/app/models/active_storage/blob.rb) and [Attachment](https://github.com/rails/rails/blob/master/activestorage/app/models/active_storage/attachment.rb) models (backed by Active Record). This means existing application models do not need to be modified with additional columns to associate with files. Active Storage uses polymorphic associations via the `Attachment` join model, which then connects to the actual `Blob`.
-These `Blob` models are intended to be immutable in spirit. One file, one blob. You can associate the same blob with multiple application models as well. And if you want to do transformations of a given `Blob`, the idea is that you'll simply create a new one, rather than attempt to mutate the existing (though of course you can delete that later if you don't need it).
+`Blob` models store attachment metadata (filename, content-type, etc.), and their identifier key in the storage service. Blob models do not store the actual binary data. They are intended to be immutable in spirit. One file, one blob. You can associate the same blob with multiple application models as well. And if you want to do transformations of a given `Blob`, the idea is that you'll simply create a new one, rather than attempt to mutate the existing one (though of course you can delete the previous version later if you don't need it).
## Examples
@@ -19,16 +18,32 @@ One attachment:
```ruby
class User < ApplicationRecord
+ # Associates an attachment and a blob. When the user is destroyed they are
+ # purged by default (models destroyed, and resource files deleted).
has_one_attached :avatar
end
-user.avatar.attach io: File.open("~/face.jpg"), filename: "avatar.jpg", content_type: "image/jpg"
+# Attach an avatar to the user.
+user.avatar.attach(io: File.open("~/face.jpg"), filename: "avatar.jpg", content_type: "image/jpg")
+
+# Does the user have an avatar?
user.avatar.attached? # => true
+# Synchronously destroy the avatar and actual resource files.
user.avatar.purge
+
+# Destroy the associated models and actual resource files async, via Active Job.
+user.avatar.purge_later
+
+# Does the user have an avatar?
user.avatar.attached? # => false
-url_for(user.avatar) # Generate a permanent URL for the blob, which upon access will redirect to a temporary service URL.
+# Generate a permanent URL for the blob that points to the application.
+# Upon access, a redirect to the actual service endpoint is returned.
+# This indirection decouples the public URL from the actual one, and
+# allows for example mirroring attachments in different services for
+# high-availability. The redirection has an HTTP expiration of 5 min.
+url_for(user.avatar)
class AvatarsController < ApplicationController
def update