| Re: [che-dev] Copy/Move with rename and overwrite pull request |
|
Hello
Sergii, I pushed another commit which addresses your comments. Please review and commit. Best regards, Ori Libhaber Ori Libhaber HANA Cloud Platform DI-Extentions Team | SAP Labs Israel | 15 Hatidhar st. | Raanana 43665, Israel T +972-(0)9-777-9830
From: che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk Hello Ori Thanks for your proposal
https://github.com/codenvy/che-core/pull/113 We just start reviewing it, Could you plz help as and take a look on comments in PR what I've made. Sergii Kabashniuk On Thu, Jun 11, 2015 at 9:37 PM, Libhaber, Ori <ori.libhaber@xxxxxxx> wrote: Hello,
I created a pull request
https://github.com/codenvy/che-core/pull/113 to address the issue described in my previous message. Summary of changes: * Changes were made to both Copy and Move service methods in che-core-api-project: additional argument
was added to both CopyOptions/MoveOptions respectively. * The body of both methods is now in the form of (application/json) { “name” : [the new name to
set] , “overwrite” : [true/false] } * The inclusion of the body is not mandatory so the API is not broken, it’s absence results in previous
system behavior for copy/move services. * Changes were also made to org.eclipse.che.vfs.imple.fs project: To be able to pass along the new
name and overwrite options, key methods and interfaces were both added and altered, keeping previous behavior intact. * Tests were added accordingly Please review and comment. B.R Ori Libhaber From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Libhaber, Ori Hello again, We are targeting a cloud environment, in which multiple REST calls are costly. If we take into account a scenario in which the user attempts to copy a file from folder A to folder
B, The number of calls in the best case would be
two (copy and then rename or vice versa) – in case of success. The number of calls in the worst case, would be
three or more (for rollback actions) – in case of naming conflicts, Goal: User want to copy and renamed file ‘a.txt’ from folder A to folder B with a new name ‘b.txt’ Assumption: folder B already contains a file named ‘a.txt’
or a file named ‘b.txt’ With current API the flow will be as follows: 1.
User copies file a.txt from folder A to folder B (POST copy/A/a.txt?to=B) 2.
2.1 2.1.1
User receives an HTTP 409 response (Resource already exists)
2.1.2 User needs thus to rename the file a.txt to say, ‘copyOfa.txt’ (POST rename/A/a.txt?name=copyOfa.txt&mediaType=text)
2.1.3 User tries again to copy file a.txt from folder A to folder B with the new name (POST
copy/A/copyOfa.txt?to=B) 2.1.4 The new name is available so the operation is successful. (HTTP response 201) 2.1.5 The user needs to rename file copyOfa.txt in folder A back to a.txt to return to previous state (POST
rename/A/a.txt name=copyOfa.txt&mediaType=text) 2.1.6 end of scenario
2.2 2.2.1 The new name is not available because (for sake of example) there is already a file named ‘b.txt’ in folder B so user gets a HTTP 409 response
(Resource already exists) 2.2.2 Temporary file ‘a.txt’ need to be cleared from folder B to return to previous state (DELETE
/B/a.txt) 2.2.3 Operation fails As can be seen in the described scenario, both flows will result in at least 3 REST calls. In contrast, let’s assume the API has the ability to copy with rename (in the request body for instance)
and also, the backend supports default new name suggestion, then the number of client REST calls for the above scenario could be reduced to a single REST call Turning the above scenario into: 1.
User copies file a.txt from folder A to folder B (POST copy/A/a.txt?to=B) 2.
If the user chooses to turn on (for instance) “auto renaming” by providing the appropriate request body the scenario could end here since backend will auto rename the target. 3.
3.1 If not then the backend can return a new name not yet used for a.txt, like ‘copyOfa1.txt’ in the response body. The user then, could choose to rename ‘a.txt’ in the target backed by a guarantee that it will not collide with any other files occupying folder
3.2 the user (again) copy ‘a.txt’ to folder B, with a new name ‘copyOfa1.txt ‘ provided in the request body. (POST
copy/A/a.txt?to=B) We would like to suggest that a new (and available) name for the file being copied will be automatically
chosen if the name provided by the user causes a conflict, similarly to how windows explorer handles such cases. Please consider the same for move with rename operation. Respectfully, Ori Libhaber Ori Libhaber HANA Cloud Platform DI-Extentions Team | SAP Labs Israel | 15 Hatidhar st. | Raanana 43665, Israel
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Micka?l Leduque Hi, I don't think that's what Ori Libhaber had in mind, but isn't there's already a problem when you want to "copy with rename" in the same directory? Mickaël LEDUQUE 2015-04-22 13:19 GMT+02:00 Gennady Azarenkov <gazarenkov@xxxxxxxxxxx>: Hi, Honestly, we've never considered dedicated method for this as you can simply copy and then rename. Please explain why this option is that important for you. Thanks
Gennady Azarenkov - CTO @
codenvy.com On Tue, Apr 21, 2015 at 3:40 PM, Libhaber, Ori <ori.libhaber@xxxxxxx> wrote:
|
