-
-
Notifications
You must be signed in to change notification settings - Fork 169
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
Meteor 3.0: Adding Async Methods to server #884
base: dev
Are you sure you want to change the base?
Conversation
📦 v2.2.0 __Breaking Changes__ -⚠️ Changes in `namingFunction`, — now naming function acts the same on the Client and Server, upon insert, load, and write. Test your implementation with changed logic. Output of Server function supersedes Client's function output __Changes__ - 📔 Merge veliovgroup#843 and fix veliovgroup#820, thanks to @Prinzhorn - 📔 Documentation refactoring focused on examples and its simplifications - 👨💻 Support nested custom path returned from `namingFunction` - 👨💻 Fix `namingFunction` behavior on Client and Server in upload, load, and write methods, closing veliovgroup#842; Thanks to @chrschae - 👷♂️ Now library exports its helpers `import { FilesCollection, helpers };` - 👷♂️ Add `.meteorignore` to minimize package's footprint
📦 v2.2.1 - 👨💻 Fix veliovgroup#842, a newly detected bug by @chrschae; Fixing case when `namingFunction` returns new nested path cause exception in `.write()` and `.load()` methods
📦 v2.3.0 __New features:__ - ✨ `opts.sanitize` method, read more in [*Constructor* docs](https://github.com/veliovgroup/Meteor-Files/blob/master/docs/constructor.md); Thanks to @xet7 and @mfilser __Other Changes:__ - 👷♂️ Minor codebase enhancements and cleanups
v2.3.1 __Changes:__ - 👨💻 Improve `createIndex` helper - 👨💻 Improve error output when FileSystem destination not writable; Related to veliovgroup#857, thanks to @Leekao - 🐞 Fix custom `allowedOrigins` option for CORS; Closing veliovgroup#850, thanks to @djlogan2; __Notes:__ - 👨🔬 Tested with latest release of `[email protected]`
📔 Improve AWS S3 documentation
📦 v2.3.2 - 👨💻 Potential fix for veliovgroup#857 (windows)
👷♂️ Update .eslintrc
📦 v2.3.3 __Major changes:__ - no __Changes:__ - 👨🔧 Fixed veliovgroup#870, thanks to @Gobliins - 🤝 Compatibility with `[email protected]`
Hi guys, please comment on this first attempt. In order to better understand what's going on I decided to add some tests for the server part, FilesCollection, core and cursor. Unfortunately this adds overall dependencies, especially in I suggest that the async versions of all the methods do not use any callbacks but throw errors instead and return promises resolving the results, cf. Which callbacks need async versions? E.g. for my project, I need an async version of |
Will try this update tomorrow and let you know how it goes (I'm on Pacific coast time :P). I've been deep into css modules all day so I'm going to have to shift a bit to deal with the files collection. |
No issues for me using |
@bratelefant @dr-dimitru Maybe it's time to release a new beta that relies on the latest RC instead of beta? |
A beta release would be awesome so I can do some integration tests with our projects and give you early feedback |
@harryadel @bratelefant @jankapunkt |
Thanks for acting so quickly @dr-dimitru 👏 |
Can you make
|
I think in general all hooks should be async. Any of them might require interacting with the database which is now something that is async by default. |
@bratelefant My only pain point so far with the current state of the PR is the lack of documentation: took me some time to figure out that the callback version of |
That'd be definitely one major point to add to this pr. Did all changes with focus on the server side, client only methods did not get touched.
Yes, in our discussion here at some point we decided to make this an update with breaking changes by removing all sync methods on the server side. @make-github-pseudonymous-again I tried to keep documention in the server side method comments aligned with the code changes, but that was definitely not checked agains tests / code. I would be really grateful if someone could jump on the bandwagon and contribute to the PR, I am having a pretty 'crunchy' time at work atm |
let _id; | ||
try { | ||
_id = await this.collection.insertAsync(helpers.clone(result)); | ||
try { | ||
await this._preCollection.updateAsync({_id: opts.fileId}, {$set: {isFinished: true}}); | ||
if (_id) result._id = _id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it conceivable that this id-setting logic sometimes fail? I have an existing test that yields fileRef._id = undefined
in the on('end')
handler of FileCollection#insert
(client-side call)`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
onUploaded
is even worse: the fileRef
is simply undefined
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bratelefant do you think we should address this as part of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm getting similar undefined
results after an upload via
ContactFileCollection.insert({
file: file,
}).on('uploaded', (uploadError, file) => {
console.log('===== uploaded', uploadError, file)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would adress it in a separete PR if it will not interfere with this one (merge conflicts etc.) otherwise directly here
Any update on this? |
Hello, I created a PR to allow us to use async onBeforeUpload bratelefant#2 |
Make onBeforeUpload async compliant
Hi everyone... Not trying to be pushy, but this is one of the few remaining hurdles in migrating to Meteor 3 for many of us. Even if it was only a new beta version adding the async onBeforeUpload changes would help... @dr-dimitru @StorytellerCZ @jankapunkt |
Hey, any updates on this ? |
Hey @wolasss @hluz @bratelefant I can take a look at this finally... may need some time though to test everything with our existing staging projects |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First of all big thanks for this PR and the all the work on this. I am currently creating a repro to test all this with a GridFS setup but it looks good for minimal functionality.
However, I found a few thinks which I commented each in the respective lines.
@dr-dimitru I think there is still the big question if there is the intent to support Meteor 2 and 3 or doing a clean break and just go for Meteor 3 and onwards.
Besides that I found there are much more things to be done after merging this pR:
- docs need to be updated
- server.js should be refactored into smaller files to reduce mental load during debugging sessions
@dr-dimitru if you have time we could get in contact this week and shortly talk about how we can move forward with this one. I'm willing to finish the great work that has been done here but I first think we need a clear mission for a stable 3.x release
const uploadInstance = new UploadInstance(config, this); | ||
if (autoStart) { | ||
uploadInstance.start().catch((error) => { | ||
console.error('[FilesCollection] [insert] Error starting upload:', error); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this error also go into onError
on the client in order to properly inform users with human readable error?
- name: setup node | ||
uses: actions/setup-node@v3 | ||
with: | ||
node-version: '14.x' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should bump to latest Node LTS (22)
runs-on: ubuntu-latest | ||
steps: | ||
- name: checkout | ||
uses: actions/checkout@v3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All GitHub core actions are in the meantime at version 4
- name: Setup meteor | ||
uses: meteorengineer/setup-meteor@v1 | ||
with: | ||
meteor-release: '2.14' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to add Matrix tests here? In Meteor Community Packages we do Matrix tests for Major Meteor versions 2.x and 3.x if packages have to support both
return this.cursor.count(); | ||
async countAsync() { | ||
this._collection._debug('[FilesCollection] [FilesCursor] [countAsync()]'); | ||
return this.cursor.countAsync(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while this is good backwards compatibility the prefereed method for counting docs is now async collection.countDocuments
and async collection.estimateDocumentCount
which are missing in the core.js
implementation of FilesCollection
fs.writeFileSync(opts.path, ''); | ||
} | ||
// check if the file already exists, otherwise create it | ||
let mustCreateFileFirst = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems to be redundant with the code in line 1278++ and could be extracted into a method
} | ||
if (opts.timeout > 0) { | ||
timer = Meteor.setTimeout(() => { | ||
controller.abort(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, that Node 14 has no native AbortController
implementation and a polyfill is needed; so this might cause issues when we want to have backwards compat with 2.x
|
||
return this; | ||
if (!result.size) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this is newly added behavior then please add a few comments. also - is pipeline
available in node 14?
const fileRef = await this.collection.findOneAsync(_id); | ||
|
||
if (proceedAfterUpload === true) { | ||
this.onAfterUpload && this.onAfterUpload.call(this, fileRef); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing await
if (files.count() > 0) { | ||
files.forEach((file) => { | ||
if (await files.countAsync() > 0) { | ||
await files.forEachAsync((file) => { | ||
this.unlink(file); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is debatable but if you want to use sequential for each async then you have to return the promise, generated by this.unlink
in order to have the underlying await
to take effect.
otherwise I don't know if this has any implications, like race condition etc.
@jankapunkt thank you for your review, I'll go though it, and see how much I can fix, then we decide if call is needed, looking forward to new beta release |
@dr-dimitru if you want you can merge this into |
This is a first try on async methods as a PR draft. Updated eslint and mocha testing as well;
core.js
andcursor.js
were a starting point. Work is progressing onserver.js
.Related to #865