You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The return values and exception propagation behavior for insert, update, and remove are currently inconsistent and undocumented. They should be changed to match the original Meteor collection API as far as reasonable.
Perhaps I can throw in here that for other operations that take an optional callback (I'm looking at you, commit), the result or error passed to the callback should be the same as the result returned or the error thrown when no callback is passed.
This might break existing apps. If we identify specific high-impact cases, we can have an option to maintain the old behavior in those cases, but the old behavior is so inconsistent that I think it's going to be unworkable to have code that exactly reproduces either the old behavior or the new behavior depending on an option. Given that the change is an important step in the cleanup of this package that will make future enhancements easier, I think it's reasonable to tell app developers that they have to update their code before they can upgrade this package and benefit from future enhancements.
The text was updated successfully, but these errors were encountered:
I think it's reasonable too, with a note in the CHANGELOG or README that backwards compatibility might be affected. I'm pretty ignorant about the right way to handle and propagate errors. Wide open to PRs on this.
The return values and exception propagation behavior for insert, update, and remove are currently inconsistent and undocumented. They should be changed to match the original Meteor collection API as far as reasonable.
Perhaps I can throw in here that for other operations that take an optional callback (I'm looking at you,
commit
), the result or error passed to the callback should be the same as the result returned or the error thrown when no callback is passed.This might break existing apps. If we identify specific high-impact cases, we can have an option to maintain the old behavior in those cases, but the old behavior is so inconsistent that I think it's going to be unworkable to have code that exactly reproduces either the old behavior or the new behavior depending on an option. Given that the change is an important step in the cleanup of this package that will make future enhancements easier, I think it's reasonable to tell app developers that they have to update their code before they can upgrade this package and benefit from future enhancements.
The text was updated successfully, but these errors were encountered: