feat: Allow File adapter to create file with specific locations or dynamic filenames #9557
Conversation
…le access to config to allow getFileLocation calls internally File adapter may specify a different filename or location during creation which should be returned after content storage. Example, adapter timestamps upload filenames. getFileLocation may result in a slightly different url than the one used to create the file. In the case where the url returned is identical this is not a problem. Additionally file adapter could call getFile location internally if it wanted to (and should probably have access to config for that reason)
Thanks for opening this pull request! |
AdrianCurtin
changed the title
AdrianCurtin
changed the title
but use updated filename in getFileLocation
|
@mtrezza |
|
@mtrezza |
|
@AdrianCurtin Thank you for picking this up again, I've restarted the CI, let's see... |
| * @discussion options are not supported by all file adapters. Check the your adapter's documentation for compatibility | ||
| * @param {Config} config - (Optional) server configuration |
There was a problem hiding this comment.
Why would the whole Parse Server config be passed into the adapter? Or am I misreading this?
There was a problem hiding this comment.
@mtrezza
Allowing the server config to be passed to the createFile would allow a couple of things.
- files can be named based on serer attributes (ex: generateKey could store log files with the app id)
- getFileLocation can be called within createFile, either to test or check that the file has been created (especially if getFileLocation depends on the server config which it always has access to)
There may be other situations in which the server config may be useful apart from customizing file paths and running getFileLocation, but I don't see why createFile shouldn't have access to it if getFileLocation does.
If this was a smaller project I would probably have refactored adapter.createFile to use config as the first argument, but that had the potential to be fairly breaking and maybe its nicer for some people to use X.createFile('filename')
In any case tacking it at the end was the compromise I made.
In the current S3-adapter PR, this only allows getFileLocation to run inside and I didn't pass the parameters to generateKey.
I would say though that removing that expectation and removing getFileLocation from the adapter would make the changes more explicit, but then [location] = createFile would not always match the call from getFileLocation (if it depended in any way on server parameters)
| it('should return valid filename or url from createFile response when provided', async () => { | ||
| const config = Config.get(Parse.applicationId); | ||
|
|
||
| // Test case 1: adapter returns new filename and url |
There was a problem hiding this comment.
Could you please split this into separate tests, each one with a distinct title to describe what it's testing.
There was a problem hiding this comment.
You also may want to take a look at the failing tests in the CI
Allow file adapter to override file name and location + give createFile access to config to allow getFileLocation calls internally
File adapter may specify a different filename or location during creation which should be returned after content storage.
Example, adapter timestamps upload filenames. getFileLocation may result in a slightly different url than the one used to create the file.
In the case where the url returned is identical this is not a problem. Additionally file adapter could call getFile location internally if it wanted to (and should probably have access to config for that reason).
In principle, if user wanted to name every file uploaded in an ordinal fashion (eg 1.jpg,2.jpg,3.jpg), they should allowed to do this.
As a separate improvement, this allows the url to be assigned during createFile as well (to prevent extra calls if the url is already known). Passing config to createFile allows getFileLocation to be called internally). Otherwise if url is not assigned, then getFileLocation can be called to retrieve it with the updated filename.
If url is not provided and filename is unchanged by createFile, then this code will not alter current functionality
Pull Request
Issue
Closes: #9556
Approach
Tasks