Perché è stato creato get.php e / o `core / file_storage_database`?

Dalla versione 1.5 o 1.6, Magento aveva un file nella cartella principale denominata get.php. Questo file, usando il core/file_storage_datamodello, consente ai proprietari del sistema Magento di servire i propri file multimediali di prodotto direttamente dalle colonne BLOB nel database senza avere un file di immagine nel file system. PHP gestisce l'invio del file

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

Questo si sta diffondendo nel territorio della storia del Magento, ma perché questa funzionalità è stata sviluppata? Sembra - leggermente pazzo. PHP non è il modo più efficiente di servire un file, l'archiviazione BLOB di MySQL ha una storia di instabilità e persino un'implementazione BLOB di database stabile è una seccatura con cui lavorare, e da quello che posso vedere Varien_File_Transfer_Adapter_Httpnon aggiunge eventuali intestazioni della cache di questi file.

Qualcuno sa perché Magento ha sviluppato questa funzione? Realizza effettivamente qualsiasi obiettivo / problema si è prefissato di risolvere? Qualcuno lo sta usando?

In realtà ho trovato l'SRS originale per questa funzione e posso condividerlo qui per scopi storici:

Attualmente non esiste altra opzione per archiviare file multimediali, ma nel file system del server Web. Questo approccio è abbastanza valido quando esiste solo un'istanza del sistema in esecuzione e il database si trova sullo stesso server dell'istanza di sistema.

Tuttavia, il modo più probabile di distribuzione del sistema non è lo stesso. I clienti hanno più istanze del sistema distribuite su server diversi, che richiedono la sincronizzazione. Questo è il motivo per cui due diverse opzioni di memorizzazione delle immagini devono essere sviluppate come opzioni: Database e CDN (Content Delivery Network).

La CDN come memoria multimediale alternativa verrà implementata nel sistema solo come opzione di supporto, non come integrazione completa con una o più CDN specifiche. L'amministratore dovrà scegliere e configurare se stesso CDN, nonché apportare lievi modifiche alla configurazione del sistema.

Non incollerò casi d'uso ma per CDN menziona solo la modifica degli URL di base per immagini / skin in URL CDN (suppongo che richieda PULL CDN)

Non l'ho provato ampiamente, né l'ho usato in produzione, ma l'ho usato per la mia guida Elastic Beanstalk + Magento . Il vantaggio è per un cluster di nodi Web che non condivide nulla: i file di immagine vengono archiviati nel back-end del DB quando caricati tramite admin e quindi inizialmente serviti da lì (e idealmente da CDN in seguito). Significa che puoi evitare NFS per la condivisione di file multimediali.

La mia ipotesi qui è che è inteso per ambienti cluster. Webnodi multipli con 1 nodo db. Se anche sessioni / cache si trovano nel db (o altro nodo) il tuo webnode verrebbe letto solo e non dovrai sincronizzare i media ogni volta che visualizzi un nuovo webnode.

Nel complesso, sono d'accordo sul fatto che sembra una soluzione ingegnerizzata alla ricerca di un problema da risolvere.

Sono stato piuttosto felice di vederlo all'interno di Magento, personalmente, perché (come altri citano) fornisce un modo per stack con più nodi Web di avere un'unica fonte autorevole delle immagini senza dover affrontare i montaggi NFS.

Se sei come me ed esegui le distribuzioni sostituendo i nodi Web in entrata e in uscita da un bilanciamento del carico (come l'utilizzo di AWS Launch Configurations / Auto Scaling Groups), questo è in realtà abbastanza sano.

In genere si desidera evitare di inserire le immagini nel DB per una serie di motivi, ma il modo in cui questo processo (in pratica) funziona è che l'immagine viene estratta dal file system locale dal DB e quindi servita da lì per le richieste successive .

Se puoi fare un ulteriore passo avanti (quindi ci sono ancora meno richieste di abbattere le immagini / riferimento dal file system) ti consiglierei di utilizzare un CDN e impostare il tuo sito Web come origine e modificare l'URL multimediale come descritto da altri.

Una nota a margine, la maggior parte delle configurazioni di MySQL avrà un valore "max_allowed_packet" molto basso che limita le dimensioni del trasferimento di dati consentito al tuo DB. Se stai pensando di archiviare le immagini nel DB, potresti voler dare un'occhiata in modo da non spararti nel piede.