Proposal: Add JSONField to django-filer's File model

[jrief]

This proposal is the sibling of django-cms/django-cms#7074

Preamble

In django-filer the File-model defined as a polymorphic model, so that other Django models can inherit from thereof. The only model, which currently makes use of this is the Image-model. In addition to the fields required for arbitrary files, it adds the image's width, height, an alt tag, the center of interest (subject_location) and a caption field.
While this seems to be a fair set of additional meta-data, images may contain much more information. If one, for instance wants to store the EXIF-headers, or copyright information, he must create his own image model and override it using the special settings variable FILER_IMAGE_MODEL. Migrating such a project can be really painful.

In addition to this, images can have various formats and an EXIF header may only make sense for JPEG. PNG images use other textual information to store their meta-data. Video and audio files may themself bring their own meta-data, and that also might be of interest without have to open the files for reading.

So, in order to store all that additional information, we would have to create a model for each specific Mime-Type. Since this is not going to happen, I would like make the following proposal to simplify django-filer:

Proposal

I would like to drop the polymorphism from django-filer's File-model and also drop django-filer's Image model. Instead I would like to add a JSONField to the File-model which is used to store all extra context data, such as width, height, copyright information, alt tags, pixel density, EXIF headers, orientation, play-length for video and audio files, etc.

This means that the File-model will keep all the fields it currently has, plus one JSONField for all the extra data. Adding additional functionality hence becomes much simpler, because we then can inherit from model File as proxy instead of a OneToOne-relation. This prevents us having to deal with foreign keys (causing lot's of database joins) and Django models distributed across different database tables as we do now.

I believe that this approach will make it much simpler to add special functionality such as video and audio re-coding or other approaches on how to set the interesting part of an image. It also makes a django-filer's File more like a Unix file, where the lower level operating system does not care about the file type. Functionality to read and manipulate those files is handled by an upper layer.

[benzkji]

yes. many times thought about this! strongly vote for it. this would make many things much more easier! go for it ;)

[macolo]

yes, that makes sense to me! From a developer's perspective this is easier to handle, using form overrides (those can even be dynamic), especially when it comes to showing different form fields for different file types. Let's do this.

[mwyser]

We currently use django-filer 2.1rc4 for our job portal project which will go live in a few weeks (we use plenty of PNGs) - and I highly appreciate your approach for json for metadata! It would open a whole new way of working with any type of media!
Strongly voting for this.

[yml]

Doing such change in a backward compatible way might be challenging. I have seen many project overriding the image model (FILER_IMAGE_MODEL).

The management pipeline for a File and Image are different as well as their UI and foreignkey widget. I can see how proxymodel for File and Image could be used instead of "polymorphic inheritance" but I can see few challenges along the way.

I think that one thing I am missing in the proposal above is Why do you think that this major change is required ?

What are the issues you are trying to solve ?

[mwyser]

I agree Jacob, Media files like PDFs (e.g. using pdfminer.parser) or MS Office documents contain a lot of metadata which can be extracted but not stored anywhere in the current model unless additional fields are added. Doing so in a json field would give gr8 flexibility to use filer in a more comprehensive way - even as a simple digital asset management system.

[yml]

Because adding additional functionality to django-filer, currently is way too complicated.

@jrief I would be interested to hear about a use case that you feel was hard or impossible to do with django-filer.

On the positive side it is right now very easy to extend the Image model with additional fields or to modify its behavior like swapping the thumbnailing pipeline.

It is also possible to extend django-filer to support you own custom type that would support your use case.

Moving away a from an "exposed" database model to some kind of jsonfield means that we are trading away some query performances and the database integrity.

In order to test the water and to breakdown the changes in smaller steps how would you feel about making the File model "swappable" in a similar way than for FILER_IMAGE_MODEL ?

[jrief]

@yml

I would be interested to hear about a use case that you feel was hard or impossible to do with django-filer.

For images we require alt tags and long descriptions in different languages. By
using the relational approach, we have to override the Image model and in
addition to that use django-parler or sortof to handle translations. This adds
to database JOINs even for very sipmle queries.
By using a JSONField, we now can handle all translations inside that single
field.

It is also possible to extend django-filer to support you own custom type that would support your use case.

I know. But this is so complicated that nobody ever offered an implementation
for say, WEBP, Audio, Video or PDF files.

Moving away a from an "exposed" database model to some kind of jsonfield means that we are trading away some query performances and the database integrity.

Did you ever filter over the width or alt tag of an image? I never even thought
about that. And even if I had to, GIN would by my friend. On the other side, we
gain a lot by not having to JOIN the Image- with the File-model.

In order to test the water and to breakdown the changes in smaller steps how would you feel about making the File model "swappable" in a similar way than for FILER_IMAGE_MODEL ?

I had to change the built-in Image-model against my own implementation by
using FILER_IMAGE_MODEL. Performing that migration on a non-empty database was
a major pain in the a... I'd really like to prevent anybody having to do such a
migration.

[yml]

@jrief we start all new projects with our own FILER_IMAGE_MODEL to avoid doing it during the lifecycle of a the project.

Your are not answering the question about opening a new world of possibility by making FILER_FILE_MODEL swappable. This would let people that wants to add a JsonField do it in a very natural and easy way. In theory they could even swap FILER_IMAGE_MODEL to a proxy model of FILER_FILE_MODEL.

[jrief]

Making FILER_FILE_MODEL swappable wouldn't simplify the code, on the contrary, we would get implementations, which will rely on the classic relational approach of handling fields, and other using the JSONField.

For the File model, adding a JSONField wouldn't change any functionality, it just would be there as a placeholder for arbitrary data. I would leave all the current fields of the File model just as they are now.

Then other implementations specializing for the corresponding file types, can use that JSONField to store their extra data. These models shall be implemented as Django proxy models.

[yml]

JsonField is not built in by default on sqlite

Does that means we would drop support for sqlite ?

[jrief]

I never experienced any problems with the JSONField on SQLite3. I wasn't even aware that in special cases you have to recompile SQLite. Anyway, all of my installations support it by default.

Does that means we would drop support for sqlite ?

For sure not. SQLite is my preferred database for testing.

[greyhare]

Some databases don't let you filter on the contents of JSONFields well... but is anyone actually putting any of these subclass model fields in a WHERE clause? I'm sure not; this data is all used after I run the query.

[marksweb]

These model changes sound sensible to me 👍