-
Notifications
You must be signed in to change notification settings - Fork 26
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
[FEAT]: Support for Files Alias Name #1076
Comments
My thoughts on implementing this are as follows:
Alternatively, we could change the usage of the name field and always use it as an "alias" but not as the way that the file is going to be stored. So files will always be stored with UUIDs, but will appear with the specified name in the db. Thoughts @Renc17, @ChrisPdgn, @kon14 ? |
Would it be wrong if we added the naming logic that exists in file systems like: "When you download a file that has an already existing name just append a '(1)' to it" ? That way we don't change anything and we just check the count of files that have this name already and add the suffix. |
@ChrisPdgn that's another behaviour that we could look into. In general uniqueness is enforced db-wise I think, can't remember precisely. So a file with name X needs to be unique across everything. But even if we consider container/bucket and folder names, this would work nicely. I don't know if it should be the default behaviour though, or if the strategy should be specified on the settings and/or the request to create the file. Meaning to pick between setting (1), (2) etc. for example or use the uuid to store the file and keep the name in the db |
done in #1096 |
Suggestion
I propose adding a new feature to the storage module that allows users to specify an alias name for uploaded files. This functionality will enable users to provide a custom name for each file upon upload, addressing potential duplication issues when files with identical names are uploaded.
To achieve this, I propose we use a generated UUID instead of indexing file names for uniqueness.
The text was updated successfully, but these errors were encountered: