Allow Cloudinary Active Storage service to reuse preloaded blobs via options (avoid extra DB queries)
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 45/100
Piste de recherche
Commencez par localiser CloudinaryService#url et l’helper privé #find_blob_or_use_key, puis examinez la façon dont #delete et #exist? appellent l’helper. Réutilisez un blob facultatif fourni via les options d’URL tout en préservant la gestion existante des clés et le comportement de fallback ; ne modifiez pas la suppression et vérifiez que le chemin d’URL évite la recherche supplémentaire du blob lorsqu’un blob est fourni.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Feature request for Cloudinary Ruby SDK
Please enhance the Cloudinary Active Storage service so that it can reuse a preloaded ActiveStorage::Blob instead of always querying the database.
I’m specifically proposing:
- Threading an optional
:blobthrough theoptionshash into the internal helper#find_blob_or_use_key. - Updating
#find_blob_or_use_keyto accept an optionalblob:parameter and use it when present. - Focusing primarily on
#urlwhile leaving#deleteand#exist?unchanged for now.
This keeps public APIs backwards compatible and only adds an opt-in optimization path.
Explain your use case
In my Rails app, ActiveStorage::Blob records are often already loaded in memory via includes / preload/with_attached_*.
When I call blob.url, Rails ends up delegating to the configured service’s #url method and passes along an options hash. I’d like to be able to include the already-loaded blob in that options hash so the Cloudinary service doesn’t need to look it up again by key.
For my specific workload, this primarily matters for generating URLs (#url), where blobs are very frequently preloaded. For deletions, blobs are less likely to be preloaded, so I’m less concerned about optimizing #delete right now.
Describe the problem you’re trying to solve
Currently:
-
CloudinaryService#find_blob_or_use_keyis a private helper used internally by:#url#delete#exist?
-
These methods pass a key to
find_blob_or_use_key, which then always does a DB lookup (unless the argument is already anActiveStorage::BlobKey). -
When calling
blob.url, Rails goes throughservice.url(key, options), and the options hash is forwarded — but there is no support in the Cloudinary service for using something likeoptions[:blob]to skip the DB query.
As a result:
- Even if I already have the
ActiveStorage::Blobinstance, the Cloudinary service will still callActiveStorage::Blob.find_by(key: key). - This can create unnecessary queries and N+1 patterns in attachment-heavy views or background jobs.
- There’s no way to opt in to a “I already have the blob, please reuse it” behavior.
#delete is more problematic to change because Blob#delete only passes the key to the service and doesn’t pass an options hash at all. In my case, blobs are less likely to be preloaded at deletion time, so I’m okay with leaving #delete as-is initially.
Do you have a proposed solution?
Yes.
1. Pass blob through the options hash for #url
Because blob.url already forwards an options hash to the service, the most compatible way is to use that:
- Allow callers of
service.url(includingblob.url) to passblobviaoptions[:blob]. - Inside
CloudinaryService#url, extractblobfromoptionsand pass it tofind_blob_or_use_key.
Conceptual example:
def url(key, filename: nil, content_type: '', **options)
blob = options[:blob]
key = find_blob_or_use_key(key, blob:)
# existing logic using key...
end
2. Update find_blob_or_use_key to accept an optional blob: argument
Then, update the private helper so that it reuses a provided blob if present, and falls back to the current behavior otherwise. For example:
def find_blob_or_use_key(key, blob: nil)
if key.is_a?(ActiveStorage::BlobKey)
key
else
begin
blob ||= ActiveStorage::Blob.find_by(key: key)
blob ? ActiveStorage::BlobKey.new(blob.attributes.as_json) : key
rescue ActiveRecord::StatementInvalid => e
# Return the original key if an error occurs
key
end
end
end
Why this is backwards compatible
-
Existing callers that do not pass a
:bloboption behave exactly as before:find_blob_or_use_keystill doesActiveStorage::Blob.find_by(key: key)and returns the same result type.- It still returns the key unchanged if it’s already an
ActiveStorage::BlobKey. - It still rescues
ActiveRecord::StatementInvalidand returns the original key.
-
The optimization is opt-in:
- Only when an upstream caller sets
options[:blob](for example,blob.url(blob: blob)or via a wrapper) will the Cloudinary service reuse the preloaded blob and skip the DB query.
- Only when an upstream caller sets
This enables applications that already manage preloaded blobs to avoid extra database queries when generating URLs (and, optionally, when checking existence), without breaking or changing the behavior for any existing users of the SDK.
- Langage dominant
- Ruby
- Étoiles
- 420
- Forks
- 282
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de cloudinary/cloudinary_gem
-
Difficulté 4/5 3-5 jours Accessibilité débutants 55/100
cloudinary/cloudinary_gem#597 · 1 commentaire ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 52/100
cloudinary/cloudinary_gem#591 · 3 commentaires ·
-
404's when fetching .eml files (from Action Mailbox)Peut-être à nouveau libre @rnamba-cloudinary l’a pris il y a 400 jours, et aucune pull request n’est ouverte. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 30/100
cloudinary/cloudinary_gem#581 · 1 commentaire ·
-
BlobKey, MirrorService and Sidekiq 8 are incompatiblePeut-être à nouveau libre @const-cloudinary l’a pris il y a 541 jours, et aucune pull request n’est ouverte. Ouverte
cloudinary/cloudinary_gem#573 · 3 commentaires · 1 personne assignée ·
-
ActiveStorage Mirror IssueOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 30/100
cloudinary/cloudinary_gem#562 · 9 commentaires ·
Toutes les issues de cloudinary/cloudinary_gem
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
metacall/core#964 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
area: ci benchmark build developer-experience difficulty: easy dx enhancement github-actions good first issue hacktoberfest help wanted performance quality rank: 8 kyu ruby tech: ruby
Difficulté 1/5 Moins d'une heure Accessibilité débutants 82/100
flisk-sh/flisk-labs#22 ·
-
1.severity: security
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
Les mainteneurs répondent en général sous 1 jour
-
15-minutes 5-minutes algorithm any-language beginner-friendly c cpp csharp easy go good first issue hacktoberfest help wanted java javascript kotlin python rust swift typescript
Difficulté 1/5 Moins d'une heure Accessibilité débutants 68/100
Huerte/algo-solutions-python#260 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour