Pourquoi get.php et / ou `core / file_storage_database` ont-ils été créés?

Depuis la version 1.5 ou 1.6, Magento avait un fichier dans le dossier racine nommé get.php. Ce fichier, en utilisant le core/file_storage_datamodèle, permet aux propriétaires de système Magento de servir leurs fichiers multimédias de produit directement à partir des colonnes d'objets blob dans la base de données sans avoir de fichier image sur le système de fichiers. PHP gère l'envoi du fichier

#File: get.php
function sendFile($file)
{
    if (file_exists($file) || is_readable($file)) {
        $transfer = new Varien_File_Transfer_Adapter_Http();
        $transfer->send($file);
        exit;
    }
}

Cela vire dans le territoire de l'histoire de Magento, mais pourquoi cette fonctionnalité a- t-elle été développée? Il semble - un peu fou. PHP n'est pas le moyen le plus efficace de servir un fichier, le stockage d'objets blob de MySQL a toujours été instable, et même une implémentation stable d'objets blob de base de données est une tâche difficile à utiliser, et d'après ce que je peux voir, Varien_File_Transfer_Adapter_Httpcela n'ajoute rien tous les en-têtes de mise en cache de ces fichiers.

Est-ce que quelqu'un sait pourquoi Magento a développé cette fonctionnalité? At-elle réellement atteint l'objectif ou le problème qu'il a cherché à résoudre? Quelqu'un l'utilise-t-il?

J'ai en fait trouvé le SRS d'origine pour cette fonctionnalité et je peux le partager ici à des fins historiques:

Il n'y a actuellement aucune autre option pour stocker des médias, mais dans le système de fichiers du serveur Web. Cette approche est suffisamment bonne lorsqu'il n'y a qu'une seule instance du système en cours d'exécution et que la base de données se trouve sur le même serveur que l'instance du système.

Cependant, le moyen le plus probable de déploiement du système n'est pas le même. Les clients ont plusieurs instances du système déployées sur différents serveurs, qui nécessitent une synchronisation. C'est pourquoi, deux options différentes de stockage d'images doivent être développées en option: la base de données et le CDN (Content Delivery Network).

Le CDN en tant que stockage multimédia alternatif sera implémenté dans le système en tant qu'option de support uniquement, et non en tant qu'intégration complète avec un ou des CDN spécifiques. L'administrateur devra choisir et configurer CDN lui-même ainsi que d'effectuer des changements mineurs dans la configuration du système.

Je ne collerai pas de cas d'utilisation, mais pour CDN, il ne mentionne que la modification des URL de base pour les images / skins en URL CDN (je suppose que cela nécessite PULL CDN)

Je ne l'ai pas testé intensivement, ni utilisé en production, mais je l'ai utilisé pour mon guide Elastic Beanstalk + Magento . L'avantage est pour un cluster de nœuds Web sans partage - les fichiers d'image sont stockés dans le backend DB lorsqu'ils sont téléchargés via admin, puis initialement servis à partir de là (et idéalement à partir de CDN après cela). Cela signifie que vous pouvez éviter NFS pour partager des médias.

Je suppose ici qu'il est destiné aux environnements de cluster. Plusieurs nœuds Web avec 1 nœud de base de données. Si les sessions / cache se trouvent également dans la base de données (ou un autre nœud), votre nœud Web serait en lecture seule et vous n'avez pas besoin de synchroniser le média chaque fois que vous ouvrez un nouveau nœud Web.

Dans l'ensemble, je suis d'accord que cela ressemble à une solution d'ingénierie à la recherche d'un problème à résoudre.

J'ai été plutôt ravi de voir cela dans Magento, personnellement, car (comme d'autres le mentionnent), il permet aux piles avec plusieurs nœuds Web d'avoir une seule source faisant autorité des images sans avoir à gérer les montages NFS.

Si vous êtes comme moi et que vous exécutez des déploiements en remplaçant des nœuds Web dans et hors d'un équilibreur de charge (par exemple, en utilisant AWS Launch Configurations / Auto Scaling Groups), cela est en fait assez sain d'esprit.

En règle générale, vous souhaiterez éviter de placer des images dans la base de données pour diverses raisons, mais la façon dont ce processus fonctionne (essentiellement) est que l'image est extraite du système de fichiers local à partir de la base de données, puis servie à partir de là pour les demandes ultérieures. .

Si vous pouvez aller plus loin (il y a donc encore moins de demandes pour extraire / référencer les images du système de fichiers), je recommanderais d'utiliser un CDN et de définir votre site Web comme origine, et de modifier l'URL du média comme décrit par d'autres.

Par ailleurs, la plupart des configurations MySQL auront une valeur "max_allowed_packet" très faible, ce qui limite la taille du transfert de données autorisé vers votre base de données. Si vous prévoyez de stocker des images dans la base de données, vous voudrez peut-être vérifier cela afin de ne pas vous tirer une balle dans le pied.