You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having the S3Upload field allows any text field on a model to become S3 compatible, however at large scale it can get out of hand - S3 interactions are spread across all models in the project. An alternative approach (which I've worked with in the past, with millions of files) is to have a single file-tracking model, and a OneToOne relationship on the model where required.
classTestModel(models.Model):
# store the upload path on the modelfile1=S3UploadField(dest='foo')
# store the upload as separate objectfile2=models.OneToOneField(S3Upload)
The advantage of this is that all uploads are held in a single table, and you can add useful metadata to each - the model field it is stored against, timestamps etc. The additional advantage is that you can then key audit events off this object - uploads, downloads etc. (See #5)
The disadvantage is that the initial implementation is harder - hooking the widget up so that you are creating the object and then the relationship to the parent, etc.
Both approaches could be combined - use the model if you want auditing, use the field if you don't.
The text was updated successfully, but these errors were encountered:
Having the
S3Upload
field allows any text field on a model to become S3 compatible, however at large scale it can get out of hand - S3 interactions are spread across all models in the project. An alternative approach (which I've worked with in the past, with millions of files) is to have a single file-tracking model, and aOneToOne
relationship on the model where required.The advantage of this is that all uploads are held in a single table, and you can add useful metadata to each - the model field it is stored against, timestamps etc. The additional advantage is that you can then key audit events off this object - uploads, downloads etc. (See #5)
The disadvantage is that the initial implementation is harder - hooking the widget up so that you are creating the object and then the relationship to the parent, etc.
Both approaches could be combined - use the model if you want auditing, use the field if you don't.
The text was updated successfully, but these errors were encountered: