Skip to content
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

Add file triggers and file meta data #6344

Merged
merged 44 commits into from
Apr 2, 2020

Conversation

stevestencil
Copy link
Contributor

@stevestencil stevestencil commented Jan 15, 2020

Closes #6340
Closes #6341

@davimacedo
Copy link
Member

@stevestencil great job here! congrats! Can you please take a look at the tests?

@stevestencil
Copy link
Contributor Author

@davimacedo I plan on putting some more work into this tomorrow. I will try to cleanup the tests as best I can. I've been having a hell of a time getting them to pass locally.

@codecov
Copy link

codecov bot commented Jan 16, 2020

Codecov Report

Merging #6344 into master will not change coverage by %.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #6344   +/-   ##
=======================================
  Coverage   93.94%   93.94%           
=======================================
  Files         169      169           
  Lines       11939    11939           
=======================================
  Hits        11216    11216           
  Misses        723      723           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cfeda1c...cfeda1c. Read the comment docs.

@stevestencil
Copy link
Contributor Author

@davimacedo @dplewis I finally got the tests to pass. I'm still not 100% on how I have the fileObject setup. I am going to work on it some more tomorrow and add some tests for my changes. I also plan to add beforeDeleteFile and afterDeleteFile hooks too. Ideally we should have beforeGetFile and afterGetFile hooks too. However it does not appear there is any way to get the user making the request because the session token is not passed in? Thanks for your feedback!

@stevestencil
Copy link
Contributor Author

stevestencil commented Jan 16, 2020

@davimacedo @dplewis How can I run just the tests that I want to add? Or even just the tests in 1 specific file? I'm much more familiar with Jest

@dplewis
Copy link
Member

dplewis commented Jan 16, 2020

@stevestencil

To run specific file:

npm test spec/MyFile.spec.js

To run specific test: use fit instead of it (don't commit fit, remember to change it back to it)

fit('myTest', done => done());

We should document fit in the Contributing guide.

@stevestencil
Copy link
Contributor Author

Ahh... much better!... Now I will feel productive again!

@stevestencil
Copy link
Contributor Author

@davimacedo @dplewis I added some tests... can you point me in the right direction with why the 1 test will not pass with postgres?

@dplewis
Copy link
Member

dplewis commented Jan 16, 2020

@stevestencil That is a flaky test. It fails randomly. I restarted the tests.

@stevestencil
Copy link
Contributor Author

Awesome... How does this look?

@stevestencil
Copy link
Contributor Author

I did just think of one other thing. If the user changes the data in the beforeSaveFile hook, the fileObject.contentLength does not get updated with the new data size when it gets passed to the afterSaveHook

@stevestencil
Copy link
Contributor Author

Also, I think adding a way the user can return an already saved Parse.File (bypassing the save to storage all together) should be added too. Any objections on making this happen?

@mman
Copy link
Contributor

mman commented Mar 29, 2020

Can’t wait to get this in, it will also address #6518 if I read the code correctly. Any help needed?

@stevestencil
Copy link
Contributor Author

@dplewis can you restart this build. 🤞🏼

@dplewis
Copy link
Member

dplewis commented Mar 29, 2020

Of course, doing an SDK release first to merge into the server

@@ -31,12 +31,14 @@ export class FilesController extends AdaptableController {
}

const location = this.adapter.getFileLocation(config, filename);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we have a problem here deciding the location prior to your hooks being called?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is the same problem as described here: #6518 the location is computed before the triggers and adapters get a chance to potentially modify the file name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is currently no way to change the name of the Parse.File because there is no setter. I believe with these hooks you could create a new Parse.File (with a new name) using the same data as the original file and return it in the hook. Your new file (with the new file name) will be saved instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stevestencil Would it be possible to add a test case for this. When a client SDK asks to save file A.txt and in beforeSave you create new File with name B.txt and the same contents, verify that it is actually saved into B.txt? That would be awesome to consider this practice as a blessed way to change filename during the upload. To explain some background. Client SDK wants to save A.txt but when pushing to S3 you want to make the filename YYYY-MM-DD-A.txt so that you can later clean up files on S3.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote a test case for your example and it passes. You'll just have to make sure preserveFileName is set to true in your parse-server config so that the random text does not get prepended to your file names.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to slow this down, I can't wait to get it in and use it in production, but what happens when preserveFileName: false which is the default. The beforeSave handler should receive a filename passed from the client sdk prepended with a random string, and will have a change to work from that, correct? It should work both ways.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, prepending a filename passed in from client SDK is fine IMHO, this is the default server behavior to make sure that all saved files are unique. The beforeSave trigged should get called on such file, and there if you change anything, it should still work, regardless whether the filename in beforeSave was kept intact from client SDL (preserveFilename: true) or whether it was prepended with random chars (preserveFilename: false - the default behavior). Correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no matter if preserveFileName is true or false, the beforeSaveFile hook will get the file name as it came from the client (lets say foo.txt)... The file name gets changed by adding the random text to the beginning of the file name inside of parse-server. if you set preserveFileName to false this will not happen.

So in a nutshell. The random text gets added after the beforeSaveFile hook and before the file actually saves to whatever storage solution you're using.

@dplewis
Copy link
Member

dplewis commented Mar 31, 2020

@stevestencil The latest version of the JS SDK has been merged.

Can you update your branch from master to see if the test run?

@stevestencil
Copy link
Contributor Author

@dplewis I did and it looks like 1 test failed... can you look and see if that's one of those flakey tests that needs to be reran?

@dplewis
Copy link
Member

dplewis commented Mar 31, 2020

It doesn't look like a flaky test. It is related to the FileController. Can you have a look?

@stevestencil
Copy link
Contributor Author

I'm on it!

@stevestencil
Copy link
Contributor Author

@dplewis I finally got them to pass 🤦🏻‍♂️

@dplewis dplewis requested review from davimacedo and acinader April 1, 2020 15:27
Copy link
Contributor

@acinader acinader left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me. some super minor comment nits...

spec/FilesController.spec.js Outdated Show resolved Hide resolved
src/Adapters/Files/FilesAdapter.js Show resolved Hide resolved
src/cloud-code/Parse.Cloud.js Outdated Show resolved Hide resolved
src/cloud-code/Parse.Cloud.js Outdated Show resolved Hide resolved
Copy link
Contributor

@acinader acinader left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@TomWFox
Copy link
Contributor

TomWFox commented Apr 4, 2020

@stevestencil If you have a chance, it would be great to add this to the cloud code guide, even just a simple mention & explanation would be fine.

I may be able to get round to this at some point if you can't but I'm busy setting up the forum right now & it would be great if you could do it because you will be able to explain it in more detail! 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
9 participants