Usage as a non-default media storage engine

[jayvdb]

So far all db media storage engines I have found all expect DEFAULT_FILE_STORAGE = '...'.

I am looking for the ability to have another storage (S3) as the default which is needed for most of the apps in the project, but use db storage for limited cases , and in my case the creation of the media files is done within the app server. i.e. I dont need to supported media uploaded into the app server. Specifically I am wanting to store invoices which we don't want pushed out to a media server. I have complete control over the code which is pushing the blob into the db, so I can instantiate a non-default storage class, and use it in any strange manner in order to get the blob into the database field.

It would be nice if the stored field in the model also knows how to get the data back out without any extra voodoo, or at least a ModelAdmin mixin that can be added to contain the extra logic so the file can be downloaded there. The Field would need to know which storage engine to use.

I am happy to muck around and experiment, but it would be nice to know from the experts here that this is not possible / has significant hurdles, and also whether this project is interested in a PR with the solution.

Or if this is already possible, it would be helpful to add the voodoo into the README or an "Advanced" docs page.

[jayvdb]

Based on the tests, it looks like it might be possible using models.FileField(storage=DatabaseStorage(..), ..) , but the test settings do set DEFAULT_FILE_STORAGE to the custom class.

[jayvdb]

#32 adjusts the tests to ensure that they do not unnecessarily rely on DEFAULT_FILE_STORAGE.

Seems to work well as non-default. We just need to describe it in the readme or elsewhere.

[johanneswilm]

@jayvdb Would you want to add some text about that to the readme?

[jayvdb]

sure.

What I propose is that the README should first provide an example model which uses storage=... and not DEFAULT_FILE_STORAGE.

Then mention that if all files in all models should be stored in the db, DEFAULT_FILE_STORAGE should be used.

My reason for that order is that a model which uses storage.. will work after only two steps (1) adding the app to INSTALLED_APPS and (2) migrating. It is also more informative earlier, helping people understand that they have control over the storage class at the model field level.

Does that sound ok?

[johanneswilm]

sure, sounds good