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
fix: don't call overloaded versions of find functions internally #13951
Conversation
This was lost in sequelize#5924, but the comments remained, rendering them contradictory. The tests demonstrate that the commented behavior is no longer happening.
This aligns our behavior with the comments again
These were all over the place, I went with what seems to be the majority
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.
Looks good! I'm not opposed to letting people override Model static methods but I think it's safer not to.
Thanks for the test file name refactor, we're slowly refactoring to a more consistent codebase :)
Thanks! And yeah, little bits here and there add up over time, figured I'd do my part 🙂 And my understanding is that folks can still override the static methods if they want (I don't think we can really prevent it) but this makes sure if they do, we at least use the internal versions for internal calls where the callers depend on them behaving in a predictable way. Which should make it harder to break things by overriding them, at least! 😄 Thanks for looking this over and getting it merged (and fixing up my PR title) |
I was wrong about the commit type, i thought it was all test related, but I think it's better with |
🎉 This PR is included in version 7.0.0-alpha.6 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Pull Request Checklist
Please make sure to review and check all of these items:
npm run test
ornpm run test-DIALECT
pass with this change (including linting)?Description Of Change
Comments in
model.js
indicated that we should avoid calling overloaded versions offindAll
andfindOne
internally, but we were in fact doing just that. It appears this behavior was lost in the transition to ES6 classes in #5924. This fixes the code behavior to match the comment (and previous behavior); if this is no longer desired the comments could just be deleted instead.