Why was get.php and/or `core/file_storage_database` Created?

Question

Since around version 1.5 or 1.6, Magento's had a file in the root folder named get.php. This file, using the core/file_storage_data model, allows Magento system owners to serve their product media files directly from blob columns in the the database without having an image file on the file system. PHP handles sending the 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;
    }
}

This is veering into Magento history territory, but why was this feature developed? It seems — slightly insane. PHP isn't the most efficient way to serve a file, MySQL's blob storage has a history of being unstable, and even a stable database blob implementation is a pain in the behind to work with, and from what I can see Varien_File_Transfer_Adapter_Http doesn't add any caching headers to these files.

Does anyone know why Magento developed this feature? Does it actually accomplish whatever goal/problem it set out to solve? Is anyone using it?

Answer 1

I actually found the original SRS for this feature and can share it here for historic purposes:

Currently there is no other option to store media, but in the file system of the web server. This approach is good enough when there is only one instance of the system running and database is located on the same server as the system instance.

However, the most likely way of system deployment is not the same. Customers have multiple instances of the system deployed on different servers, which require synchronization. This is why, two different options of storing images are to be developed as options: Database and CDN (Content Delivery Network).

CDN as alternate media storage will be implemented in the system as a support option only, not as a full integration with a specific CDN(s). The admin will have to choose and configure CDN himself as well as to perform minor changes in the system configuration.

I won't paste use cases but for CDN it only mentions changing Base URLs for images/skins to CDN url (i assume it requires PULL CDN)

Answer 2

I've not tested it extensively, nor used it in production, but used it for my Elastic Beanstalk + Magento guide. The benefit is for a share-nothing web node cluster - the image files get stored in the DB backend when uploaded via admin, and then initially served from there (and ideally from CDN after that). It means you can avoid NFS for sharing media.

Answer 3

My guess here is that it is intended for cluster environments. Multiple webnodes with 1 db node. If sessions/cache are also in the db (or other node) your webnode would be read only and you do not have to sync media any time you bring up a new webnode.

Overall I agree that it looks like an engineered solution looking for a problem to solve.

Answer 4

I was rather delighted to see this within Magento, personally, because (as others are mentioning) it provides a way for stacks with multiple web nodes to have a single authoritative source of the images without having to deal with NFS mounts.

If you're like me, and run deploys by replacing web nodes in and out of a load balancer (such as using AWS Launch Configurations / Auto Scaling Groups), this is actually quite sane.

Typically you'd want to avoid putting images in the DB for a variety of reasons, but the way that this process (basically) works is the image is pulled onto the local file system from the DB, and then served from there for subsequent requests.

If you can take it a step further (so there's even fewer requests to pull the images down/reference from file system) I'd recommend using a CDN and setting your website as the origin, and altering the media URL as described by others.

On a side note, most MySQL configs will have a very low "max_allowed_packet" value which limits the size of data transfer allowed to your DB. If you're planning on storing images in the DB, you may wanna check that out so you don't shoot yourself in the foot.