Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add file triggers and file meta data #6344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add file triggers and file meta data #6344
Changes from all commits
3e6de75
7ce5209
a8d404e
00a6b27
d41d035
288bb2a
c3470bb
0863e84
7d0c4e2
eecc3ff
93c9548
c22ef49
8d1576b
1c389ce
22a2699
70a4c81
370d091
c4f6bd4
663e355
5b1c0f4
14b41b3
a0087a0
d89b358
2982df9
ac5ba86
2cfe086
36222dc
0c4e191
51db0a6
221eafb
711c9fd
946014d
299135d
476052d
70f9b30
f6ddc0b
f43c26c
ffad97c
f34a8db
deea148
b7edf4b
bed35c9
859a603
cfeda1c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we have a problem here deciding the location prior to your hooks being called?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is the same problem as described here: #6518 the location is computed before the triggers and adapters get a chance to potentially modify the file name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is currently no way to change the name of the Parse.File because there is no setter. I believe with these hooks you could create a new Parse.File (with a new name) using the same data as the original file and return it in the hook. Your new file (with the new file name) will be saved instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stevestencil Would it be possible to add a test case for this. When a client SDK asks to save file A.txt and in beforeSave you create new File with name B.txt and the same contents, verify that it is actually saved into B.txt? That would be awesome to consider this practice as a blessed way to change filename during the upload. To explain some background. Client SDK wants to save A.txt but when pushing to S3 you want to make the filename YYYY-MM-DD-A.txt so that you can later clean up files on S3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote a test case for your example and it passes. You'll just have to make sure preserveFileName is set to true in your parse-server config so that the random text does not get prepended to your file names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to slow this down, I can't wait to get it in and use it in production, but what happens when
preserveFileName: false
which is the default. The beforeSave handler should receive a filename passed from the client sdk prepended with a random string, and will have a change to work from that, correct? It should work both ways.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In other words, prepending a filename passed in from client SDK is fine IMHO, this is the default server behavior to make sure that all saved files are unique. The beforeSave trigged should get called on such file, and there if you change anything, it should still work, regardless whether the filename in beforeSave was kept intact from client SDL (
preserveFilename: true
) or whether it was prepended with random chars (preserveFilename: false
- the default behavior). Correct?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no matter if preserveFileName is true or false, the beforeSaveFile hook will get the file name as it came from the client (lets say foo.txt)... The file name gets changed by adding the random text to the beginning of the file name inside of parse-server. if you set preserveFileName to false this will not happen.
So in a nutshell. The random text gets added after the beforeSaveFile hook and before the file actually saves to whatever storage solution you're using.