Fix tedious connect deprecation#12182
Conversation
|
Edit: I just created a unit test to tell if connect is called when state is initialized. I'm not sure if that is a great test. |
UziTech
changed the title
Codecov Report
@@ Coverage Diff @@
## master #12182 +/- ##
=======================================
Coverage 96.33% 96.34%
=======================================
Files 95 95
Lines 9179 9181 +2
=======================================
+ Hits 8843 8845 +2
Misses 336 336
Continue to review full report at Codecov.
|
|
Thanks for this fix. When can we expect it to be on v5? At the moment it has been added only to v6. Thanks. |
|
If someone opens a PR for v5, it will get auto released on merge |
|
this fix is available in v5.21.10 |
|
Thanks! |
| if (connection.state === connection.STATE.INITIALIZED) { | ||
| connection.connect(); | ||
| } |
There was a problem hiding this comment.
@UziTech I don't think you should be checking against state here. Just calling .connect should be just fine. 🤔
There was a problem hiding this comment.
Unless the user is using an old version of tedious where calling connect would throw an error.
There was a problem hiding this comment.
But this Code leads to an unhandled exception if used with msnodesqlv8 instead of tedious.
connection.state is undefined as well as connection.STATE, so it will throw a cannot read property INITIALIZED of undefined Error.
Could you please check if connection.STATE is defined before accessing INITIALIZED? Checking if .connect exists would not be suitable because msnodesqlv8 does not require the .connect() call at all, this is done in the Constructor already.
There was a problem hiding this comment.
@killerfurbel This code is not supposed to work with msnodesqlv8 in the first place. It has a completely different API than tedious.
There was a problem hiding this comment.
Really? See https://github.com/TimelordUK/node-sqlserver-v8#use-with-sequelize ... and why does sequelize support the dialectModule property in the constructor, if tedious is the only choice?
I agree, tedious is built in, therefore it is possibly the first choice for most users. But it is possible to use others and this code breaks it... I don't think it has a completely different API - it has a specific sequelize connector (https://github.com/TimelordUK/node-sqlserver-v8/blob/master/lib/sequelize/connection.js).
There was a problem hiding this comment.
I think the main idea behind dialectModule is so you can e.g. use e.g. a forked version of tedious or any other connector used by sequelize.
The way that msnodesqlv8 build compatibility for sequelize "works", but I'm not sure that is a robust approach. Shouldn't there be a separate dialect for msnodesqlv8 if that is supposed to be a fully supported option?
There was a problem hiding this comment.
Sequelize is not designed to work with msnodesqlv8
There was a problem hiding this comment.
and this code breaks it... I don't think it has a completely different API
If it wants to keep working with sequelize it could add a STATE property.
There was a problem hiding this comment.
I created an issue in the msnodesqlv8 repo: TimelordUK/node-sqlserver-v8#159
However, since you backported this behavior also to v5, I would strongly vote for a check within sequelize or revert the commit in the v5 branch. I think "removing" a depreciation warning by implementing a breaking change is not reasonable and should only happen in a major release (--> 6.x).
There was a problem hiding this comment.
You could create a PR to check for STATE. That would probably be the best chance of getting it changed.
5 participants
Pull Request check-list
Please make sure to review and check all of these items:
npm run testornpm run test-DIALECTpass with this change (including linting)?Description of change
Call
connectafter creatingtediousconnection if required.Fixes #12181