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
feat(model): add option to return raw query #11881
Conversation
Codecov Report
@@ Coverage Diff @@
## main #11881 +/- ##
=======================================
Coverage ? 96.25%
=======================================
Files ? 94
Lines ? 9214
Branches ? 0
=======================================
Hits ? 8869
Misses ? 345
Partials ? 0 Continue to review full report at Codecov.
|
4131e9b
to
271c08b
Compare
This would be a great addition that our organization would use immediately. Any chance we can get feedback on whether this is a good approach? |
271c08b
to
057b7b5
Compare
@dleo9307 What is the timeframe on this getting merged / released? |
@@ -975,8 +975,13 @@ class QueryInterface { | |||
|
|||
async select(model, tableName, optionsArg) { | |||
const options = { ...optionsArg, type: QueryTypes.SELECT, model }; | |||
const query = this.QueryGenerator.selectQuery(tableName, options, model); |
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 like this should be const query = this.queryGenerator.selectQuery(tableName, options, model);
Hey there :) First of all: Thanks a bunch for your contribution to Sequelize! Much appreciated! A couple of months ago, we have switched from master to main branch as our primary development branch and hence this PR is now outdated :( If you still think this change is making sense, please consider recreating the PR against ✌️ |
@sdepold Can you comment on whether this is the right approach for retrieving the raw sql? It feels like there has been hardly any discussion from maintainers regarding this PR (maybe I'm missing something). We would love to get this merged into a mainline branch but curious what the likelihood is of that happening. |
057b7b5
to
b5fb1f6
Compare
@sdepold updated the PR and it's now against |
Do I dare hope this is about to make it into sequelize?! 😍 |
if it is WIP: Can we maybe convert it into a draft PR? |
fwiw: I just rebased. main is now including some bits and pieces about typescript. it shouldn't make a huge diff |
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.
Thanks for your contribution @seromenho, and sorry for the late response!
I've marked two things that I would change about this PR.
There's also a problem inside our lib/model.js
, where we make use of the select
method.
Lines 1754 to 1770 in 4071378
const results = await this.queryInterface.select(this, this.getTableName(selectOptions), selectOptions); | |
if (options.hooks) { | |
await this.runHooks('afterFind', results, options); | |
} | |
//rejectOnEmpty mode | |
if (_.isEmpty(results) && options.rejectOnEmpty) { | |
if (typeof options.rejectOnEmpty === 'function') { | |
throw new options.rejectOnEmpty(); | |
} | |
if (typeof options.rejectOnEmpty === 'object') { | |
throw options.rejectOnEmpty; | |
} | |
throw new sequelizeErrors.EmptyResultError(); | |
} | |
return await Model._findSeparate(results, options); |
We have a problem here because our result is processed further, we will have to check for these scenarios as well. An early return might be a good solution
Also, I'm unsure if we should limit this option for findAndCountAll
, findAll
and findOne
queries, but it might as well make sense to separate this into multiple PRs
@@ -90,7 +90,10 @@ const Hooks = { | |||
|
|||
async runHooks(hooks, ...hookArgs) { | |||
if (!hooks) throw new Error('runHooks requires at least 1 argument'); | |||
|
|||
// Skip hooks if we are only getting raw SQL | |||
if (hookArgs[0] && typeof hookArgs[0] === 'object' && hookArgs[0].getRawSql) { |
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.
Hooks can also modify the resulting query, such as beforeFind
. I think it's best if we modify our lib/model.js
to ignore specific hooks.
@@ -949,11 +949,12 @@ class QueryInterface { | |||
|
|||
async select(model, tableName, optionsArg) { | |||
const options = { ...optionsArg, type: QueryTypes.SELECT, model }; | |||
const query = this.queryGenerator.selectQuery(tableName, options, model); | |||
if (options.getRawSql) { |
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 unsure if getRawSql
is the best name for this option, I would probably go with something like queryOnly
, getQuery
, query
or something else that more universally expresses what the expected return type is.
One note I have about this PR is that we should avoid having different return types for our functions. It makes typing them and using them with TypeScript much more complicated. Instead, let's add a new method that does this. Maybe |
When do you plan to merge this PR? We really need that feature. |
I'm closing this issue because as indicated here, we're working on making QueryGenerator a public API instead, combined with this other solution and this one |
I know there was talks about making the |
A part of me is sad to look back and see my first comment on this thread was four years ago. I think it's worth merging this PR, assuming it's ready or can be modified easily, as a stop gap until new features or v7 arrives. |
I've needed this for years for different projects, and I've always monkey-patched it. It may not cover every case, but something to the effect of:
I hope to see it in the framework proper someday as well. |
@Nick-Riggs Our team has had to do something similar because we have a dynamic query layer based on the sequelize ORM. |
@ephys this seems like a pretty big want/need from the community, are we able to look at this again? I Just note again most ORMs I've dealt with have offered easy exposure of the SQL they're building within the ORM builder itself, it'd be nice if sequlize kept to that convention:
|
Pull Request check-list
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
Usage
Implements #2325
I'll come back to this and improve the PR description and add some tests if someone confirms this is a good direction.
Thanks