mongoose
mongoose copied to clipboard
Automattic
About asynchronous getters/setters again
I have read the two discussions (#2571 and #517) that relate to this opportunity, and still do not see any reason to abandon it. Why not? Even if Mongoose should maintain compatibility with the ES5, this does not prevent to check that the setter returns to us. Watch this pseudo-code:
if (setterResult.constructor.name === 'Promise' && setterResult.then) {
promisesArray.push(setterResult.then(
value => {
return {
path: path,
value: value
};
},
err => {
return err;
}
));
}
// ...
if (promisesArray.length){
return Promise.all(promisesArray).then(
results => {
for (let result of results) {
// Do anything with it
}
// Do anything with all fields
return this.save();
},
errors => {
for (let err of errors) {
// Do anything with it
}
return errors;
}
);
} else {
// Do anything with all fields
return this.save();
}
So why not? This is a very useful feature, and it will join naturally in existing.
Yeah async setters would be useful. It's more difficult than you think, because the setter would need to resolve before doing validate(), and you'd need to return a promise from .set() because .set() can throw an error if there's a cast error.
Would love to see that coming in Mongoose ! Do you plan to implement that in a next release @vkarpov15 ?
@maxs15 possibly. Still haven't investigated how we would implement this feature, so uncertain.
I've written a little plugin to mock async getters/setters until it lands in the core. It uses different properties (read instead of get and write instead of set) to simplify things and middleware (pre init and post save for getters and pre save for setters). It is by no means perfect (I'm especially not happy how it interacts with validators) but it gets the job done.
You can try it here and leave your opinion.
I like this plugin but there's a few caveats, we'd also have to integrate this queries, because we also support doing things like findByIdAndUpdate(doc, doc)
Resurrecting this old thread since it is still the latest for this issue, and trying to bump it for visibility.
For my use case, I have a couple of fields that need to be encrypted with libsodium before saving, and that needs to be done asynchronously. As of now I can't use neither get/set, nor a virtual getter/setter and had to settle on using a pre save method which is far from ideal.
pre('save') is our recommended approach right now. Async getters are likely to be tricky to implement in general because JSON.stringify(), res.json() in Express, etc. are synchronous. But async setters could be more doable with the exception of validateSync().
That is what I have done for now @vkarpov15 , created 2 middlewares to intercept the call
ItemSchema.pre(/save|create/, encryptionMethodMiddleware);
ItemSchema.pre(
/findOneAnd(?:Replace|Update)|bulkWrite|(?:insert|update)Many/,
encryptionQueryMethodMiddleware
);
It is not as clean as I wanted and it need an extra getter to decrypt, but for now it worked
What we usually do is either 1) put async logic in the business logic rather than a hook or setter, or 2) put encrypted data in a separate model. But registering middleware on all those functions also works well.