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
Based on the discussion in issue #62, it looks like there would be a benefit in supporting custom StoredUpload models. This adds to an earlier request for this functionality raised in #45.
This would address the issue where there is a need to link mulitple stored uploads to some other model instance.
At present this could be done by modifying StoredUpload to add a ForeignKey to the required application model. This implements a one-to-many relationship using Django's reverse implementation approach where it is implemented as a many-to-one relationship adding the ForeignKey on the object that represents the "many" side of the relationship. Modifying StoredUpload is not an ideal or recommended solution since it makes maintenance more complicated and also creates a strong link to django-drf-filepond meaning that the library can't be easily upgraded to a new version without making custom modifications.
Creating an intermediate model that contains multiple instances linking a single application model instance to each required django-drf-filepondStoredUpload instance is an alternative option. This is effectively the same as using a ManyToManyField on the application model to link to multiple StoredUpload instances, although I suppose this would be considered bad practice since it is actually modelling a one-to-many relationship but using a many-to-many as a workaround to avoid having to modify StoredUpload.
To resolve these challenges, a better option would be to support the use of a custom StoredUpload model that extends django-drf-filepond's StoredUpload. A setting DJANGO_DRF_FILEPOND_STORED_UPLOAD_MODEL or similar would then allow the custom model to be permanently selected, or a custom_model attribute on the store_upload API call would allow specifying the model on a case-by-case basis. stored_upload would then accept a dictionary of additional keyword arguments representing additional data to store in the custom model instance.
The text was updated successfully, but these errors were encountered:
I think this is going to have to be pushed back to v0.7.0 (or a 0.6 patch release) - I'm currently trying to get a 0.6 release out and unfortunatley won't have the time to work on this right away. Apologies for the long delay.
Based on the discussion in issue #62, it looks like there would be a benefit in supporting custom
StoredUpload
models. This adds to an earlier request for this functionality raised in #45.This would address the issue where there is a need to link mulitple stored uploads to some other model instance.
At present this could be done by modifying
StoredUpload
to add aForeignKey
to the required application model. This implements a one-to-many relationship using Django's reverse implementation approach where it is implemented as a many-to-one relationship adding theForeignKey
on the object that represents the "many" side of the relationship. ModifyingStoredUpload
is not an ideal or recommended solution since it makes maintenance more complicated and also creates a strong link to django-drf-filepond meaning that the library can't be easily upgraded to a new version without making custom modifications.Creating an intermediate model that contains multiple instances linking a single application model instance to each required django-drf-filepond
StoredUpload
instance is an alternative option. This is effectively the same as using aManyToManyField
on the application model to link to multipleStoredUpload
instances, although I suppose this would be considered bad practice since it is actually modelling a one-to-many relationship but using a many-to-many as a workaround to avoid having to modifyStoredUpload
.To resolve these challenges, a better option would be to support the use of a custom
StoredUpload
model that extends django-drf-filepond'sStoredUpload
. A settingDJANGO_DRF_FILEPOND_STORED_UPLOAD_MODEL
or similar would then allow the custom model to be permanently selected, or acustom_model
attribute on thestore_upload
API call would allow specifying the model on a case-by-case basis. stored_upload would then accept a dictionary of additional keyword arguments representing additional data to store in the custom model instance.The text was updated successfully, but these errors were encountered: