<commit_before>---
title: Shrine for CarrierWave Users
---

This guide is aimed at helping CarrierWave users transition to Shrine, and it
consists of three parts:

1. Explanation of the key differences in design between CarrierWave and Shrine
2. Instructions how to migrate and existing app that uses CarrierWave to Shrine
3. Extensive reference of CarrierWave's interface with Shrine equivalents

## Overview

### Uploader

Shrine shares CarrierWave's concept of **uploaders**, classes which encapsulate
file attachment logic for different file types:

```rb
class ImageUploader < Shrine
  # attachment logic
end
```

However, while CarrierWave uploaders are responsible for most of the
attachment logic (uploading to temporary/permanent storage, retrieving the
uploaded file, file validation, processing versions), Shrine distributes
these responsibilities across several core classes:

| Class                  | Description                                                        |
| :----                  | :-----------                                                       |
| `Shrine`               | handles uploads, metadata extraction, location generation          |
| `Shrine::UploadedFile` | exposes metadata, implements downloading, URL generation, deletion |
| `Shrine::Attacher`     | handles caching & storing, dirty tracking, persistence, versions   |

Shrine uploaders themselves are functional: they receive a file on the input
and return the uploaded file on the output. There are no state changes.
<commit_msg>Update carrierwave.md<commit_after>---
title: Shrine for CarrierWave Users
---

This guide is aimed at helping CarrierWave users transition to Shrine, and it
consists of three parts:

1. Explanation of the key differences in design between CarrierWave and Shrine
2. Instructions how to migrate an existing app that uses CarrierWave to Shrine
3. Extensive reference of CarrierWave's interface with Shrine equivalents

## Overview

### Uploader

Shrine shares CarrierWave's concept of **uploaders**, classes which encapsulate
file attachment logic for different file types:

```rb
class ImageUploader < Shrine
  # attachment logic
end
```

However, while CarrierWave uploaders are responsible for most of the
attachment logic (uploading to temporary/permanent storage, retrieving the
uploaded file, file validation, processing versions), Shrine distributes
these responsibilities across several core classes:

| Class                  | Description                                                        |
| :----                  | :-----------                                                       |
| `Shrine`               | handles uploads, metadata extraction, location generation          |
| `Shrine::UploadedFile` | exposes metadata, implements downloading, URL generation, deletion |
| `Shrine::Attacher`     | handles caching & storing, dirty tracking, persistence, versions   |

Shrine uploaders themselves are functional: they receive a file on the input
and return the uploaded file on the output. There are no state changes.

{'fraction_non_alphanumeric': 0.06484196806777452, 'fraction_numerical': 0.0019550342130987292, 'mean_word_length': 2.8423028785982476, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 10, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2311875', 'n_tokens_mistral': 749, 'n_tokens_neox': 664, 'n_words': 329}