shrine 3.0.0.rc → 3.0.0

data/doc/metadata.md

@@ -1,4 +1,6 @@
-# Extracting Metadata
+---
+title: Extracting Metadata
+---
 
 Before a file is uploaded, Shrine automatically extracts metadata from it, and
 stores them in the `Shrine::UploadedFile` object.
@@ -386,5 +388,5 @@ end
 [MiniMagick]: https://github.com/minimagick/minimagick
 [ruby-vips]: https://github.com/libvips/ruby-vips
 [tus server]: https://github.com/janko/tus-ruby-server
-[determine_mime_type]: /doc/plugins/determine_mime_type.md#readme
-[backgrounding]: /doc/plugins/backgrounding.md#readme
+[determine_mime_type]: https://shrinerb.com/docs/plugins/determine_mime_type
+[backgrounding]: https://shrinerb.com/docs/plugins/backgrounding

data/doc/multiple_files.md

@@ -1,4 +1,7 @@
-# Multiple Files
+---
+id: multiple-files
+title: Multiple Files
+---
 
 There are times when you want to allow users to attach multiple files to a
 single resource, like an album having many photos or a playlist having many
@@ -11,7 +14,7 @@ relationship with the main table, and files will be attached on the records in
 the new table. That way each record from the main table can implicitly have
 multiple attachments through the associated records.
 
-```
+```plaintext
 album1
   photo1
     - attachment1
@@ -64,8 +67,9 @@ files (or attachments) table will be the photos table.
 Let's create a table for the main resource and attachments, and add a foreign
 key in the attachment table for the main table:
 
+<!--DOCUSAURUS_CODE_TABS-->
+<!--Sequel-->
 ```rb
-# with Sequel:
 Sequel.migration do
   change do
     create_table :albums do
@@ -80,8 +84,9 @@ Sequel.migration do
     end
   end
 end
-
-# with Active Record:
+```
+<!--ActiveRecord-->
+```rb
 class CreateAlbumsAndPhotos < ActiveRecord::Migration
   def change
     create_table :albums do |t|
@@ -97,21 +102,25 @@ class CreateAlbumsAndPhotos < ActiveRecord::Migration
   end
 end
 ```
+<!--END_DOCUSAURUS_CODE_TABS-->
 
 In the Photo model, create a Shrine attachment attribute named `image`
 (`:image` matches the `_data` column prefix above):
 
+<!--DOCUSAURUS_CODE_TABS-->
+<!--Sequel-->
 ```rb
-# with Sequel:
 class Photo < Sequel::Model
   include ImageUploader::Attachment(:image)
 end
-
-# with Active Record:
+```
+<!--ActiveRecord-->
+```rb
 class Photo < ActiveRecord::Base
   include ImageUploader::Attachment(:image)
 end
 ```
+<!--END_DOCUSAURUS_CODE_TABS-->
 
 ### 2. Declare nested attributes
 
@@ -120,8 +129,9 @@ Using nested attributes is the easiest way to implement any dynamic
 relationship to the photos table, and allow it to directly accept attributes
 for the associated photo records by enabling nested attributes:
 
+<!--DOCUSAURUS_CODE_TABS-->
+<!--Sequel-->
 ```rb
-# with Sequel:
 class Album < Sequel::Model
   one_to_many :photos
   plugin :association_dependencies, photos: :destroy # destroy photos when album is destroyed
@@ -129,13 +139,23 @@ class Album < Sequel::Model
   plugin :nested_attributes
   nested_attributes :photos, destroy: true
 end
-
-# with Active Record:
+```
+<!--ActiveRecord-->
+```rb
 class Album < ActiveRecord::Base
   has_many :photos, dependent: :destroy
   accepts_nested_attributes_for :photos, allow_destroy: true
 end
 ```
+<!--Mongoid-->
+```rb
+class Album
+  include Mongoid::Document
+  embeds_many :photos
+  accepts_nested_attributes_for :photos
+end
+```
+<!--END_DOCUSAURUS_CODE_TABS-->
 
 Documentation on nested attributes:
 
@@ -152,20 +172,9 @@ already created photos, so that the same form can be used for updating the
 album/photos as well (they will be submitted under the
 `album[photos_attributes]` parameter).
 
+<!--DOCUSAURUS_CODE_TABS-->
+<!--Rails form builder-->
 ```rb
-# with Forme:
-form @album, action: "/photos", enctype: "multipart/form-data" do |f|
-  f.input :title
-  f.subform :photos do # adds new `album[photos_attributes]` parameter
-    f.input :image,   type: :hidden, value: f.obj.cached_image_data
-    f.input :image,   type: :file
-    f.input :_delete, type: :checkbox unless f.obj.new?
-  end
-  f.input "files[]", type: :file, attr: { multiple: true }, obj: nil
-  f.button "Create"
-end
-
-# with Rails form builder:
 form_for @album, html: { enctype: "multipart/form-data" } do |f|
   f.text_field :title
   f.fields_for :photos do |p| # adds new `album[photos_attributes]` parameter
@@ -177,6 +186,20 @@ form_for @album, html: { enctype: "multipart/form-data" } do |f|
   f.submit "Create"
 end
 ```
+<!--Forme-->
+```rb
+form @album, action: "/photos", enctype: "multipart/form-data" do |f|
+  f.input :title
+  f.subform :photos do # adds new `album[photos_attributes]` parameter
+    f.input :image,   type: :hidden, value: f.obj.cached_image_data
+    f.input :image,   type: :file
+    f.input :_delete, type: :checkbox unless f.obj.new?
+  end
+  f.input "files[]", type: :file, attr: { multiple: true }, obj: nil
+  f.button "Create"
+end
+```
+<!--END_DOCUSAURUS_CODE_TABS-->
 
 In your controller you should still be able to assign all the attributes to the
 album, just remember to whitelist the new parameter for the nested attributes,
@@ -261,18 +284,21 @@ class ImageUploader < Shrine
   end
 end
 ```
+<!--DOCUSAURUS_CODE_TABS-->
+<!--Sequel-->
 ```rb
-# with Sequel:
 class Album < Sequel::Model
   # ... (nested_attributes already enables validating associated photos) ...
 end
-
-# with ActiveRecord:
+```
+<!--ActiveRecord-->
+```rb
 class Album < ActiveRecord::Base
   # ...
   validates_associated :photos
 end
 ```
+<!--END_DOCUSAURUS_CODE_TABS-->
 
 Note that by default only metadata set on the client side will be available for
 validations. Shrine will not automatically run metadata extraction for directly
@@ -294,8 +320,8 @@ attributes feature gives you for free.
 [`Sequel::Model.nested_attributes`]: http://sequel.jeremyevans.net/rdoc-plugins/classes/Sequel/Plugins/NestedAttributes.html
 [`ActiveRecord::Base.accepts_nested_attributes_for`]: http://api.rubyonrails.org/classes/ActiveRecord/NestedAttributes/ClassMethods.html
 [`Mongoid::Document.accepts_nested_attributes_for`]: https://docs.mongodb.com/mongoid/master/tutorials/mongoid-nested-attributes/
-[`upload_endpoint`]: /doc/plugins/upload_endpoint.md#readme
-[`presign_endpoint`]: /doc/plugins/presign_endpoint.md#readme
+[`upload_endpoint`]: https://shrinerb.com/docs/plugins/upload_endpoint
+[`presign_endpoint`]: https://shrinerb.com/docs/plugins/presign_endpoint
 [Uppy]: https://uppy.io
 [direct app uploads]: https://github.com/shrinerb/shrine/wiki/Adding-Direct-App-Uploads
 [direct S3 uploads]: https://github.com/shrinerb/shrine/wiki/Adding-Direct-S3-Uploads

data/doc/paperclip.md

@@ -1,4 +1,6 @@
-# Shrine for Paperclip Users
+---
+title: Shrine for Paperclip Users
+---
 
 This guide is aimed at helping Paperclip users transition to Shrine, and it
 consists of three parts:
@@ -7,9 +9,52 @@ consists of three parts:
 2. Instructions how to migrate and existing app that uses Paperclip to Shrine
 3. Extensive reference of Paperclip's interface with Shrine equivalents
 
-## Storages
+## Overview
 
-In Paperclip the storage is configure inside the global options:
+### Uploader
+
+In Paperclip, the attachment logic is configured directly inside Active Record
+models:
+
+```rb
+class Photo < ActiveRecord::Base
+  has_attached_file :image,
+    preserve_files: true,
+    default_url:    "/images/:style/missing.png"
+
+  validated_attachment_content_type :image, content_type: "image/jpeg"
+end
+```
+
+Shrine takes a more object-oriented approach, by encapsulating attachment logic
+in "uploader" classes:
+
+```rb
+class ImageUploader < Shrine
+  plugin :keep_files
+  plugin :default_url
+  plugin :validation_helpers
+
+  Attacher.default_url do |derivative: nil, **|
+    "/images/#{derivative}/missing.png" if derivative
+  end
+
+  Attacher.validate do
+    validate_mime_type %w[image/jpeg]
+  end
+end
+```
+```rb
+class Photo < ActiveRecord::Base
+  include ImageUploader::Attachment(:image)
+end
+```
+
+### Storage
+
+Paperclip storage is configured together with other attachment options. Also,
+the storage implementations themselves are mixed into the attachment class,
+which couples them to the attachment flow.
 
 ```rb
 class Photo < ActiveRecord::Base
@@ -24,7 +69,8 @@ class Photo < ActiveRecord::Base
 end
 ```
 
-In contrast, a Shrine storage is just a class which you configure individually:
+Shrine storage objects are configured separately and are decoupled from
+attachment:
 
 ```rb
 Shrine.storages[:store] = Shrine::Storage::S3.new(
@@ -35,10 +81,8 @@ Shrine.storages[:store] = Shrine::Storage::S3.new(
 )
 ```
 
-Paperclip doesn't have a concept of "temporary" storage, so it cannot retain
-uploaded files in case of validation errors, and [direct S3 uploads] cannot be
-implemented in a safe way. Shrine uses separate "temporary" and "permanent"
-storage for attaching files:
+Shrine also has a concept of "temporary" storage, which enables retaining
+uploaded files in case of validation errors and [direct uploads].
 
 ```rb
 Shrine.storages = {
@@ -47,43 +91,79 @@ Shrine.storages = {
 }
 ```
 
-## Uploaders
+### Persistence
 
-While in Paperclip you define all your uploading logic inside your models,
-Shrine takes a more object-oriented approach and lets you define uploading logic
-inside "uploader" classes:
+When using Paperclip, the attached file data will be persisted into several
+columns:
+
+* `<name>_file_name`
+* `<name>_content_type`
+* `<name>_file_size`
+* `<name>_updated_at`
+* `<name>_created_at` (optional)
+* `<name>_fingerprint` (optional)
+
+In contrast, Shrine uses a single `<name>_data` column to store data in JSON
+format:
 
 ```rb
-class Photo < ActiveRecord::Base
-  has_attached_file :image
-end
+{
+  "id": "path/to/image.jpg",
+  "storage": "store",
+  "metadata": {
+    "filename": "nature.jpg",
+    "size": 4739472,
+    "mime_type": "image/jpeg"
+  }
+}
 ```
-
 ```rb
-class ImageUploader < Shrine
-  # ...
-end
+photo.image.id          #=> "path/to/image.jpg"
+photo.image.storage_key #=> :store
+photo.image.metadata    #=> { "filename" => "...", "size" => ..., "mime_type" => "..." }
 
-class Photo < ActiveRecord::Base
-  include ImageUploader::Attachment(:image)
-end
+photo.image.original_filename #=> "nature.jpg"
+photo.image.size              #=> 4739472
+photo.image.mime_type         #=> "image/jpeg"
 ```
 
-Among other things, this allows you to use uploader classes standalone, which
-gives you more power:
+This column can be queried if it's made a JSON column. Alternatively, you can
+use the [`metadata_attributes`][metadata_attributes] plugin to save metadata
+into separate columns.
+
+#### ORM
+
+While Paperclip works only with Active Record, Shrine is designed to integrate
+with any persistence library (there are integrations for [Active
+Record][activerecord], [Sequel][sequel], [ROM][rom], [Hanami][hanami] and
+[Hanami][mongoid]), and can also be used standalone:
 
 ```rb
-uploaded_file = ImageUploader.upload(File.open("nature.jpg"), :store)
-uploaded_file     #=> #<Shrine::UploadedFile>
-uploaded_file.url #=> "https://my-bucket.s3.amazonaws.com/store/kfds0lg9rer.jpg"
+attacher = ImageUploader::Attacher.new
+attacher.attach File.open("nature.jpg")
+attacher.file #=> #<Shrine::UploadedFile @id="f4ba5bdbf366ef0b.jpg" ...>
+attacher.url  #=> "https://my-bucket.s3.amazonaws.com/f4ba5bdbf366ef0b.jpg"
+attacher.data #=> { "id" => "f4ba5bdbf366ef0b.jpg", "storage" => "store", "metadata" => { ... } }
 ```
 
-### Processing
+#### Location
+
+Paperclip persists only the filename of the uploaded file, and recalculates the
+full location dynamically based on location configuration. This can be
+dangerous, because if some component of the location happens to change, all
+existing links might become invalid.
 
-In contrast to Paperclip's static options, in Shrine you define and perform
-processing on instance-level. You also have the descriptive method names
-provided by the [image_processing] gem.
+To avoid this, Shrine persists the full location on attachment, and uses it
+when generating file URL. So, even if you change how file locations are
+generated, existing files that are on old locations will still remain
+accessible.
+
+### Processing
 
+In Shrine, processing is defined and performed on the instance level, which
+gives you more control. You're also not coupled to ImageMagick, e.g. you can
+use [libvips] instead (both integrations are provided by the [image_processing]
+gem).
 
 ```rb
 class Photo < ActiveRecord::Base
@@ -114,25 +194,51 @@ class ImageUploader < Shrine
 end
 ```
 
+Shrine is agnostic as to how you're performing your processing, so you can
+easily use any other processing tools. You can also combine different
+processors for different versions.
+
+#### Retrieving versions
+
+When retrieving versions, Paperclip returns a list of declared styles which
+may or may not have been generated. In contrast, Shrine persists data of
+uploaded processed files into the database (including any extracted metadata),
+which then becomes the source of truth on which versions have been generated.
+
+```rb
+photo.image              #=> #<Shrine::UploadedFile @id="original.jpg" ...>
+photo.image_derivatives  #=> {}
+
+photo.image_derivatives! # triggers processing
+photo.image_derivatives  #=>
+# {
+#   large: #<Shrine::UploadedFile @id="large.jpg" @metadata={"size"=>873232, ...} ...>,
+#   medium: #<Shrine::UploadedFile @id="medium.jpg" @metadata={"size"=>94823, ...} ...>,
+#   small: #<Shrine::UploadedFile @id="small.jpg" @metadata={"size"=>37322, ...} ...>,
+# }
+```
+
 #### Reprocessing versions
 
 Shrine doesn't have a built-in way of regenerating versions, because that has
-to be written and optimized differently depending on whether you're adding or
-removing a version, what ORM are you using, how many records there are in the
-database etc. The [Managing Derivatives] guide provides some useful tips on
-this task.
+to be written and optimized differently depending on what versions have changed
+which persistence library you're using, how many records there are in the table
+etc.
+
+However, there is an extensive guide for [Managing Derivatives], which provides
+instructions on how to make these changes safely and with zero downtime.
 
-### Validations
+### Validation
 
-Validations are also defined inside the uploader on the instance-level, which
-allows you to do conditional validations:
+File validation in Shrine is also instance-level, which allows using
+conditionals:
 
 ```rb
 class Photo < ActiveRecord::Base
   has_attached_file :image
   validates_attachment :image,
-    content_type: {content_type: %w[image/jpeg image/png image/gif]},
-    size: {in: 0..10.megabytes}
+    size: { in: 0..10.megabytes },
+    content_type: { content_type: %w[image/jpeg image/png image/webp] }
 end
 ```
 
@@ -141,114 +247,53 @@ class ImageUploader < Shrine
   plugin :validation_helpers
 
   Attacher.validate do
-    validate_mime_type %w[image/jpeg image/gif image/png]
     validate_max_size 10*1024*1024
+
+    if validate_mime_type %w[image/jpeg image/png image/webp]
+      validate_max_dimensions [5000, 5000]
+    end
   end
 end
 ```
 
-#### MIME type spoofing
-
-Paperclip detects MIME type spoofing, in the way that it extracts the MIME type
-from file contents using the `file` command and MimeMagic, compares it to the
-value that the `mime-types` gem determined from file extension, and raises a
-validation error if these two values mismatch.
-
-However, this turned out to be very problematic, leading to a lot of valid
-files being classified as "spoofed", because of the differences of MIME
-type databases between the `mime-types` gem, `file` command, and MimeMagic.
-
-Shrine takes a different approach here. By default it will extract MIME
-type from file extension, but it has a plugin for determining MIME type from
-file contents, which by default uses the `file` command:
-
-```rb
-Shrine.plugin :determine_mime_type
-```
-
-However, it doesn't try to compare this value with the one from file extension,
-it just means that now this value will be used for your MIME type validations.
-With this approach you can still prevent malicious files from being attached,
-but without the possibility of false negatives.
-
-### Logging
-
-In Paperclip you enable logging by setting `Paperclip.options[:log] = true`,
-however, this only logs ImageMagick commands. Shrine has full logging support,
-which measures processing, uploading and deleting individually:
-
-```rb
-Shrine.plugin :instrumentation
-```
-```
-Metadata (32ms) – {:storage=>:store, :io=>StringIO, :uploader=>Shrine}
-Upload (1523ms) – {:storage=>:store, :location=>"ed0e30ddec8b97813f2c1f4cfd1700b4", :io=>StringIO, :upload_options=>{}, :uploader=>Shrine}
-Exists (755ms) – {:storage=>:store, :location=>"ed0e30ddec8b97813f2c1f4cfd1700b4", :uploader=>Shrine}
-Download (1002ms) – {:storage=>:store, :location=>"ed0e30ddec8b97813f2c1f4cfd1700b4", :download_options=>{}, :uploader=>Shrine}
-Delete (700ms) – {:storage=>:store, :location=>"ed0e30ddec8b97813f2c1f4cfd1700b4", :uploader=>Shrine}
-```
-
-## Attachments
+#### Custom metadata
 
-While Paperclip is designed to only integrate with ActiveRecord, Shrine is
-designed to be completely generic and integrate with any ORM. It ships with
-plugins for ActiveRecord and Sequel:
+With Shrine you can also extract and validate any custom metadata:
 
 ```rb
-Shrine.plugin :activerecord # if you're using ActiveRecord
-Shrine.plugin :sequel       # if you're using Sequel
-```
+class VideoUploader < Shrine
+  plugin :add_metadata
+  plugin :validation
 
-Instead of giving you class methods for defining attachments, in Shrine you
-generate attachment modules which you simply include in your models, which
-gives your models similar set of methods that Paperclip gives:
+  add_metadata :duration do |io|
+    FFMPEG::Movie.new(io.path).duration
+  end
 
-```rb
-class Photo < Sequel::Model
-  include ImageUploader::Attachment(:image)
+  Attacher.validate do
+    if file.duration > 5*60*60
+      errors << "must not be longer than 5 hours"
+    end
+  end
 end
 ```
 
-### Attachment column
+#### MIME type spoofing
 
-Unlike in Paperclip which requires you to have 4 `<attachment>_*` columns, in
-Shrine you only need to have a single `<attachment>_data` text column (in the
-above case `image_data`), and all information will be stored there.
+Paperclip attempts to detect MIME type spoofing, which turned out to be
+unreliable due to differences in MIME type databases between different ruby
+libraries.
 
-```rb
-photo.image_data #=>
-# {
-#   "storage" => "store",
-#   "id" => "photo/1/image/0d9o8dk42.png",
-#   "metadata" => {
-#     "filename"  => "nature.png",
-#     "size"      => 49349138,
-#     "mime_type" => "image/png"
-#   }
-# }
+Shrine on the other hand simply allows you to determine MIME type from file
+content, which you can then validate.
 
-photo.image.original_filename #=> "nature.png"
-photo.image.size              #=> 49349138
-photo.image.mime_type         #=> "image/png"
+```rb
+Shrine.plugin :determine_mime_type, analyzer: :marcel
 ```
-
-Unlike Paperclip, Shrine will store this information for each processed
-version, making them first-class citizens:
-
 ```rb
-photo.image               #=> #<Shrine::UploadedFile>
-photo.image.width         #=> 800
-
-photo.image(:thumb)       #=> #<Shrine::UploadedFile>
-photo.image(:thumb).width #=> 300
+file = uploader.upload StringIO.new("<?php ... ?>")
+file.mime_type #=> "application/x-php"
 ```
 
-Also, since Paperclip stores only the filename, it has to recalculate the full
-location each time it wants to generate the URL. That makes it really difficult
-to move files to a new location, because changing how the location is generated
-will now cause incorrect URLs to be generated for all existing files. Shrine
-calculates the whole location only once and saves it to the column.
-
 ## Migrating from Paperclip
 
 You have an existing app using Paperclip and you want to transfer it to Shrine.
@@ -476,10 +521,18 @@ Shrine has this functionality in the `determine_mime_type` plugin.
 This section explains the equivalent of Paperclip attachment's methods, in
 Shrine this is an instance of `Shrine::UploadedFile`.
 
-#### `#url`, `#styles`
+#### `#url`
 
-If you're generating versions in Shrine, the attachment will be a hash of
-uploaded files:
+In Shrine you can generate URLs with `#<name>_url`:
+
+```rb
+photo.image_url         #=> "https://example.com/path/to/original.jpg"
+photo.image_url(:large) #=> "https://example.com/path/to/large.jpg"
+```
+
+#### `#styles`
+
+In Shrine you can use `#<name>_derivatives` to retrieve a list of versions:
 
 ```rb
 photo.image_derivatives #=>
@@ -489,9 +542,9 @@ photo.image_derivatives #=>
 #   large:  #<Shrine::UploadedFile>,
 # }
 
-photo.image(:small).url #=> "..."
+photo.image_derivatives[:small] #=> #<Shrine::UploadedFile>
 # or
-photo.image_url(:small) #=> "..."
+photo.image(:small) #=> #<Shrine::UploadedFile>
 ```
 
 #### `#path`
@@ -510,7 +563,7 @@ guide provides some useful tips on how to do this.
 
 ### `Paperclip::Storage::S3`
 
-The built-in [`Shrine::Storage::S3`] storage is a direct replacement for
+The built-in [`Shrine::Storage::S3`][S3] storage is a direct replacement for
 `Paperclip::Storage::S3`.
 
 #### `:s3_credentials`, `:s3_region`, `:bucket`
@@ -527,36 +580,21 @@ Shrine::Storage::S3.new(
 )
 ```
 
-#### `:s3_headers`
+#### `:s3_headers`, `:s3_permissions`, `:s3_metadata`
 
-The object data can be configured via the `:upload_options` hash:
+These can be configured via the `:upload_options` option:
 
 ```rb
-Shrine::Storage::S3.new(upload_options: { content_disposition: "attachment" }, **options)
-```
-
-You can use the `upload_options` plugin to set upload options dynamically.
-
-#### `:s3_permissions`
-
-The object permissions can be configured with the `:acl` upload option:
-
-```rb
-Shrine::Storage::S3.new(upload_options: { acl: "private" }, **options)
-```
-
-You can use the `upload_options` plugin to set upload options dynamically.
-
-#### `:s3_metadata`
-
-The object metadata can be configured with the `:metadata` upload option:
-
-```rb
-Shrine::Storage::S3.new(upload_options: { metadata: { "key" => "value" } }, **options)
+Shrine::Storage::S3.new(
+  upload_options: {
+    content_disposition: "attachment",         # headers
+    acl:                 "private",            # permissions
+    metadata:            { "key" => "value" }, # metadata
+  },
+  **options
+)
 ```
 
-You can use the `upload_options` plugin to set upload options dynamically.
-
 #### `:s3_protocol`, `:s3_host_alias`, `:s3_host_name`
 
 The `#url` method accepts a `:host` option for specifying a CDN host. You can
@@ -580,8 +618,13 @@ s3.upload(io, "object/destination/path")
 The Shrine storage has no replacement for the `:url` Paperclip option, and it
 isn't needed.
 
-[file]: http://linux.die.net/man/1/file
-[Managing Derivatives]: /doc/changing_derivatives.md#readme
-[direct S3 uploads]: /doc/direct_s3.md#readme
-[`Shrine::Storage::S3`]: /doc/storage/s3.md#readme
+[Managing Derivatives]: https://shrinerb.com/docs/changing-derivatives
+[direct uploads]: https://shrinerb.com/docs/getting-started#direct-uploads
+[S3]: https://shrinerb.com/docs/storage/s3
 [image_processing]: https://github.com/janko/image_processing
+[libvips]: http://libvips.github.io/libvips/
+[activerecord]: https://shrinerb.com/docs/plugins/activerecord
+[sequel]: https://shrinerb.com/docs/plugins/sequel
+[rom]: https://github.com/shrinerb/shrine-rom
+[hanami]: https://github.com/katafrakt/hanami-shrine
+[mongoid]: https://github.com/shrinerb/shrine-mongoid