feat: Allow File adapter to create file with specific locations or dynamic filenames #9557
Conversation
Thanks for opening this pull request! |
AdrianCurtin
changed the title
AdrianCurtin
changed the title
|
@mtrezza |
|
@mtrezza |
|
@AdrianCurtin Thank you for picking this up again, I've restarted the CI, let's see... |
…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)
but use updated filename in getFileLocation
📝 WalkthroughWalkthroughFilesAdapter.createFile gains a final config parameter; FilesController.createFile supplies that config to the adapter, uses adapter-returned name to override filename and adapter-returned url (or getFileLocation fallback) for the stored URL. Tests updated/added to validate new call signature and adapter return permutations. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant FilesController
participant FilesAdapter
Client->>FilesController: createFile(filename, data, contentType, options)
FilesController->>FilesAdapter: createFile(filename, data, contentType, options, config)
FilesAdapter-->>FilesController: { name?, url? } or undefined
alt adapter provides name
FilesController->>FilesController: filename = result.name
end
alt adapter provides url
FilesController->>FilesController: url = result.url
else
FilesController->>FilesAdapter: getFileLocation(config, filename)
FilesAdapter-->>FilesController: url
end
FilesController-->>Client: { url, name: filename }
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Pre-merge checks (4 passed, 1 warning)❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
@mtrezza any chance to run the workflow ? |
|
Done |
|
@AdrianCurtin how does the S3 PR play with this one parse-community/parse-server-s3-adapter#242 Both are needed ? |
|
This PR was designed to respect legacy behavior (or else personally I would have moved config to the first argument to match getFileLocation's argument order). For a fileadapter that does not return result.name or result.url, there should be no breaking changes. So old s3 adapters and other fileadapters should continue to function as is. The pr for the s3 adapter parse-community/parse-server-s3-adapter#242 will take this argument but won't actually return the proper location (url) without the config being passed. So if this PR is merged then 242 can function and preserve filenames. But if this PR is not merged, 242 will still run, but won't preserve the filenames (legacy behavior). Both need to be merged in order to fix the issue, but if either is merged (or for instance an older parse-server with a newer s3 adapter), it should behave with legacy behaviors. |
|
I think i've a last question @AdrianCurtin : how the fallback approach of createdFile.url || getFileLocation, play in case of using "publicServerUrl", does the adapter is aware of the publicServerUrl to return appropriate path (like https://example.com/parse/files/xxxxxxx.jpeg) and not the url of the Storage provider, since parse-server support proxying files |
|
@Moumouls So really calling getFileLocation here is just a thing that would happen if the url wasn't provided by the createFile itself (current behavior). As long as getFileLocation respects the public url it should still work as expected. As implemented, a user who does not use some argument (like generate key) to modify the filename would ideally not see any difference in behavior and the createdFile.url || getFileLocation fallback would simply prevent getFileLocation from being called twice when it already gave you an answer once. (getFileLocation function always being accessible within the file adapter itself, but requiring the config to be called). On the other hand, if an adapter createFile opted to return a url that was different than the call from getFileLocation (for instance hypothetically a resolved ip address or something) then this would break the functionality you mentioned. But if they instead opted to not return anything or call getFileLocation internally, then there would be no change in behavior. I delegated this to the file adapter in the case the getFileLocation might be pre-computed or some other variation and prevent some redundant processing, or some file adapter that might need to modify the filename based on the result of getFileLocation (for instance an invalid character) or something. (but I didn't do any of this in the s3 adapter pr, it just calls getFileLocation so that create file directly returns whatever it was supposed to. |
|
So to summarize, if developer use generateKey and public server url, the system give priority to created URL not the public one. question: does the current generateKey usage with public server url and parse file proxy activated behave this way ? it could be interesting to cover this, and check if we have a related bug, or to unsure we don't break existing parse server using generateKey with parse proxy, but seems weird since your current PR here and on S3 actually fix the implementation of generateKey which is currently broken if i understand correctly |
|
generate_key i think is a specific s3 adapter functionality and the preserve filenames also must be enabled too, so its a double-opt-in there to even begin to play with the filenames. Frankly i don't know if the parse file proxy works at all with S3 adapter (i have never tried). But in theory if it worked, generate key should have nothing to do with the parse file proxy since it's exclusively modifying the filename (and potentially s3 path by extension). The generate key does not play with the s3 root itself. But lets say that the internal call in the s3 adapter was not to url = await getFileLocation, but instead to url = await getResolvedFileLocationNoProxy() Then in this hypothetical example the url's would not match because getFileLocation and getResolvedFileLocationNoProxy would produce different results. So the only way to break parse proxy behavior is to either a) use a getFileLocation that does not respect parse proxy behavior in the first place, or b) use a novel getFileLocation internally or method that does not respect the parse proxy behavior. But option a) would obviously break that function anyways and b) might be more particular. Maybe a note for future developers or a test should basically say that createFileresult.url should match getFileLocation unless there is a specific requirement for them to differ. We could use an additional test for this, but that actually could be a valid behavior? Consider a situation where you want the file to be accessible once and never again, createFileResult.url could be an accessor returned by file creation and getFileLocation for generic file access. In either case this is an opt-in behavior by the developer of the adapter, opt-out should simply return the file location. |
|
Maybe a simpler answer would be that yes it gives preference to the created url, but in most cases this is expected to be the same as the public server url. Generate key should have nothing to do with it. The developer of the adapter would need to intentionally return a different created url than would be expected. |
|
okay @mtrezza seems good to me may be we need another final approval from another contributor @dplewis ? to move forward ? Thanks @AdrianCurtin for your detailed answers and the time spent into this PR ! |
|
Could you please look at the open conversations and close the ones that are done? Would also be good to have another AI agent look over the changes and potential implications. |
|
@Moumouls I think most of the conversations here are resolved. Anything I got back for this part from AI agents was mostly concerning passing the full config for the server var into the file adapter. Which could contain information if the file adapter wasn't privileged to know it. However the fact that the file adapter gets the information from getFileLocation anyways kind of makes that a moot point. It wouldn't be a bad idea to in the future restrict which extensions/adapters get the full file adapter info, but for the sake of this particular PR that would be a much more significant revision and could break behaviors where other people use such terms. (not during create file specifically but elsewhere). |
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
Summary by CodeRabbit
New Features
Documentation
Tests