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
Django's FileFields are very special under the hood. I wonder if we should implement support for them to some degree, esp. around the file contents (the db part should already work).
Basic problem around filefields is the fact, that they are not solely db-driven anymore, thus we'd need a sidepath to handle the file content somehow. The file content stuff looks a bit like a SEP (someone else's problem) to me, as the lib is mainly about fast turning of db entries. Still from dev-user's viewpoint it might come handy to be able to do batch manipulations on file contents as well.
But before investigating in such a direction - is fast updating file content of filefields an issue at all? Or is this rather such a rare edge case we should not bother with at all? Plz vote or comment below, whether there is any practical use for that or if thats a bad idea from a "separation of concerns" viewpoint for this lib.
The text was updated successfully, but these errors were encountered:
Django's FileFields are very special under the hood. I wonder if we should implement support for them to some degree, esp. around the file contents (the db part should already work).
Basic problem around filefields is the fact, that they are not solely db-driven anymore, thus we'd need a sidepath to handle the file content somehow. The file content stuff looks a bit like a SEP (someone else's problem) to me, as the lib is mainly about fast turning of db entries. Still from dev-user's viewpoint it might come handy to be able to do batch manipulations on file contents as well.
But before investigating in such a direction - is fast updating file content of filefields an issue at all? Or is this rather such a rare edge case we should not bother with at all? Plz vote or comment below, whether there is any practical use for that or if thats a bad idea from a "separation of concerns" viewpoint for this lib.
The text was updated successfully, but these errors were encountered: