muyangye commented on issue #2181: URL: https://github.com/apache/streampipes/issues/2181#issuecomment-1835891868
Hi @bossenti @tenthe, just to let you know I am actively working on this issue. I have one question on backward compatibility though: Currently the `FileMetadata` class has an internal file name and an original file name and I plan to just merge them into one file name. However, this may cause negative effects on current processes because of backward compatibility. For example, the [delete](https://github.com/apache/streampipes/blob/cb07ea3590733709075e3f30b7b5210fe9d117d0/streampipes-pipeline-management/src/main/java/org/apache/streampipes/manager/file/FileManager.java#L84) functionality relies on the internal file name. After letting this delete function use the merged single file name, users will not be able to delete the old already existing files because they are not found since they use internal file names. I propose 2 solutions: 1. Keep the internal file name, also let fetching/deleting files/other processes keep relying on internal file name, change is only when storing new files, just set internal file name to be the same as uploaded file name instead of random UUID. This approach solves the issue of backward compatibility and later uploads will follow the expected behavior outlined in this issue. But this causes the storage to have some (already existing) files' internal file name set to random UUID and some (after this change) files' internal file name set to uploaded file name. Also, for those existing files, users will lose original file names and see a bunch of random UUIDs in the front end which is confusing. 2. Make an announcement to users to let them delete existing files before a release. This is better technically but is going to cause troubles to users. Let me know which one do you prefer and I am definitely willing to discuss other solutions too! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
