Node-mssql: Is this project maintained?

[dcherman]

Over the last several months, there have been several pull requests and issues that have had no response. Where necessary, I'm happy to do some digging (at least into the reports I make if not other related ones), but want to ensure that the effort isn't wasted if no one with commit access is even reading this.

That said, I do want to say thanks for all of the work that you've done to provide this lib!

[elhigu]

I've been doing some stress testing (for knex library) by cutting connections all the time while making queries and noticed that pool hangs pretty easily in that kind of situation. I could write test case to show the problems, but I would appreciate if some maintainer would confirm that it wont be in vain. Meanwhile I just try to come up with some workaround... like checking that pool.available, pool.pending and pool.borrowed are not all zeroes.

ps. being able to use this library without using its internal connection pool would be really nice...

EDIT: I was able to trace this issue to actually tedious driver. In some cases when connecting the connect nor error events are not launched and connection is closed, so poolCreate hangs until timeout and after timeout pool doesn't seem to reset properly either.

Now there is pull request to fix that which also listens end event from tedious to notice if connection was closed before connect event https://github.com/tediousjs/node-mssql/pull/614

[rujorgensen]

My conclusion by now is, it's dead :). If someone would just do a fork, we could all continue from there.

[jimmont]

I believe it recently moved from @patriksimek to this @tediousjs org which suggests the org members Ben @ben-page and Bret @bretcope might be taking it over....checking

[bretcope]

@jimmont I don't have any involvement these days. I contributed to Tedious for a while, but haven't in years since I don't work with node.js much anymore. I also don't have any knowledge about who is or isn't working on this project.

[patriksimek]

@dcherman @elhigu @rujorgensen @jimmont I moved mssql under Tedious org after a short discussion with @arthurschreiber. My current occupation doesn't allow me to work on this project so I asked him if he and people from Microsoft would be interested in the future maintenance of mssql. The response was positive so you can expect more activity in the weeks to come. I hope I'll be able to contribute more on mssql in the future. Thank you for your patience and sorry for not being active over the past few months.

[jimmont]

Thanks very much @patriksimek, appreciate all your help and work. @arthurschreiber how can we (here) help and when is the best/appropriate time and place to check back? Thanks!

[elhigu]

@patriksimek thanks for the update. I was able to write test / patch for the pool hanging when tedious is having rare type of connection problems. I'll send pull request for that later on and hope it gets merged at some point. Fix is very simple one... test is not that simple :)

[ben-page]

I have been the primary maintainer tedious-connection-pool for the last few years. And I created the tediousjs group a while back with the hope that the tedious maintainers would help out with tedious-connection-pool. At the time, I suggested that we integrate the projects. But I did nothing more to pursue this. I wasn't even aware of node-mssql until this thread.

However, I no longer user MSSQL with nodejs at my work. And my personal life has become quite busy. I don't have my time to give these projects. But I would be happy to commit some time to resolving the current issues, if we can also being on new maintainers.

That said, node-mssql appears also support connection pooling and much more. Is there any reason to maintain both?

[spanditcaa]

I was interested in taking over as maintainer for tedious-connection-pool in the issue Ben linked, above as that is the pool library that my company has been using for 5+ years. That said, if node-mssql is the pool of choice I'd be happy to contribute here as well (and migrate our apps over). We just need something up to date for tedious.

[arthurschreiber]

Hey all! 👋

It'd be great if going forward, we could figure out how people are using node-mssql, and why they're using node-mssql over plain tedious.

I think clearing this up could help us to understand how to move forward. I know that node-mssql is an abstraction layer over tedious and the Microsoft SQL Server driver. But is that necessary, going forward? I'm asking because Microsoft themselves recommend (and contribute to) tedious, and supporting two drivers has a non-zero maintenance cost.

If there are people that really depend on the Microsoft SQL Server driver, what could we do to make these people switch from to tedious?

Also, what features does node-mssql provide on top of tedious? Maybe those should be integrated into tedious instead?

There's many questions here that I'd love to get feedback on. 🙇 ❤️

[jimmont]

Hey @arthurschreiber How? I started using node-mssql over tedious because it had mssql in the name along with clear examples in the README (searched npm for mssql in a rush to get things done over hunting around to figure out what module to use). Now I'm looking at using tedious instead due to this ownership issue and associated wait times for pull requests and issues.

[rujorgensen]

I'm on board with @jimmont, I'm using node-mssql because it had simple examples, had 'node' and 'mssql' in its name, and (as far as I remember) a lot of users. I will look into switching to plain Tedious if that is the general recommendation in here. :)

I wasn't even aware of Tedious before I began getting data type deprecation-warnings lately.

Happy to see all the activity 👍!

[elhigu]

I think clearing this up could help us to understand how to move forward. I know that node-mssql is an abstraction layer over tedious and the Microsoft SQL Server driver. But is that necessary, going forward?

Does tedious work directly on windows?

[arthurschreiber]

Thanks for all the replies so far!

I will look into switching to plain Tedious if that is the general recommendation in here. :)

I want to be clear here that I don't want to kill off node-mssql. @patriksimek put in a lot of work into node-mssql and tedious, and just telling users to "switch to tedious, it's better" would be a lie.

But as a long-time maintainer of tedious and now the interim maintainer for node-mssql I want to understand what features - besides being able to switch the underlying driver - are important for users.

If it's missing features, we should validate whether it might make sense to pull those into tedious.
If it's differences in the API, maybe changing the APIs in tedious would make sense?

I think one potential long term plan could be to add what is missing from tedious to be a full replacement for the Microsoft SQL Server driver, and then maybe merge tedious and node-mssql into a single package, with a clear migration path. Alternatively, node-mssql could stay it's own package and be a thin layer on top of tedious instead.

[arthurschreiber]

Does tedious work directly on windows?

Yes. There is some functionality that is missing, like windows integrated authentication, but we're working on it.

[bretcope]

I haven't used either in a few years now, but at one point we were using node-mssql mostly because it had a friendlier API. I always found using Tedious directly to be... well, tedious. We eventually switched to using a different wrapper I wrote called Tedium because we wanted a nicer async API (via generators - before async/await was available). Or course, then we abandoned node.js, so I haven't done anything with it in three years.

[mparq]

Thanks for your hard work in maintaining this project, @patriksimek!

@arthurschreiber, I do think there was value in node-mssql providing a higher level abstraction which takes care of connection pooling, which it doesn't seem like tedious does. It did turn out to result in some hard-to-track-down performance issues possibly stemming from the underlying pooling logic that node-mssql used, but at the same time I would think that rolling our own pooling logic would be nontrivial, though we never had to try and it seems to make sense for the library to provide an abstraction over that. (We didn't know about tedious-connection-pool at the time, but we also needed integrated Windows auth and integrated Azure AD auth for Azure SQL which was/is not supported in tedious also).

[Favna]

@arthurschreiber concerning

It'd be great if going forward, we could figure out how people are using node-mssql, and why they're using node-mssql over plain tedious.

For me the answer is very simple: If promises are at all supported in tedious then it is not in the initial documentation and I absolutely get disgusted by callbacks and the inevitable callback hell it creates. No instead I look towards wrappers such as mssql that allow me to natively use promises and/or aync/await in my code.

Furthermore, the documentation documentation for tedious on the github.io site, the only site linked on the repo, shows no signs of being maintained with the copyright notice having expired 3 years ago (it says 2011-2014) and has a general user interface of, pardon my french, a crappy 2008 website. This repository on the other hand has all documentation right in the center view in the readme.

[goloroden]

Promises respectively async/await is the biggest advantage of mssql over tedious IMHO. If tedious had this, I would not have a problem to switch. But going back to callbacks? Nah, no way 🙄

[jimmont]

Given the lack of activity on this issue (and growing number of pull-requests and open issues) I'm currently moving away from node-mssql to tedious-wrapper. Has anyone else formed an opinion to stay or move to another solution to ease use of sql-server or has experience with a specific solution to share/suggest (including updates about the status of node-mssql)? Thanks.

[ghost1face]

I'm in here for the same reasons, I prefer the Promise support. Also needed Integrated Security so this provides the option to use on windows with mssqlnodev8 or tedious. I'm starting a project that could definitely use this library, I've also made a few commits in the past few days and hoping to get them in and some support going.

I'm also willing to help where possible with reviewing, testing, bugs etc.

[patriksimek]

This project is maintained, again. Hooray!

I've just released a new version with a lot of fixes and some new features. To make sure I didn't break anything, I've released it with the next tag. So, to install version 4.2, please use npm i mssql@next. I'll change it to latest if there'll be no problem reported in days to come.

And now a few words about what brought me back to maintain the project. I don't like to see how this project is getting abandoned. People are creating new forks or building new wrappers. I don't think that's good for the community. The database driver is a very intimate component of any software - in bad hands, it can be easily misused and do some pretty serious damage.

The node-mssql is doing almost 70% of tedious' traffic on npm. Even though Microsoft recommends people to use tedious. That convinced me that there's definitely need to maintain the driver.

I've received some requests from people interested in maintaining the repo, but none of them seemed trustworthy to me. Sorry if it was you and you read this. Maybe I'm paranoid, but I take security seriously.

So, what's next? That depends on @tediousjs/tedious. I like the idea of merging this project with tedious. I don't care about name or credits, I do care about the result. I have no problem killing off this project if it makes sense and if there is an adequate replacement for it. And if I can help you with that, I'll be happy to. Until then, I'll do my best to keep node-mssql bugless and up-to-date.

Here is a list short list of major advantages over tedious:

• easy to use API
• rich documentation
• multiple coding styles (async/await, promise, callback, stream, tagged templates)
• built-in connection pool
• possibility to switch driver if you need to use windows auth
• geography, geometry, for json path support

[arthurschreiber]

This project is maintained, again. Hooray!

🎉 ❤️

And now a few words about what brought me back to maintain the project. I don't like to see how this project is getting abandoned. People are creating new forks or building new wrappers. I don't think that's good for the community. The database driver is a very intimate component of any software - in bad hands, it can be easily misused and do some pretty serious damage.

The node-mssql is doing almost 70% of tedious' traffic on npm. Even though Microsoft recommends people to use tedious. That convinced me that there's definitely need to maintain the driver.

I agree, and I have to admit I have not been doing a great job here. It's been incredibly hard for to maintain just tedious, and taking on node-mssql as well has turned out to be too much. 😞

I've received some requests from people interested in maintaining the repo, but none of them seemed trustworthy to me. Sorry if it was you and you read this. Maybe I'm paranoid, but I take security seriously.

I've made a similar, but different experience. People often suggest changes or fixes that fix an issue they are running into (that is great!), but often those fixes are handed over in a way that is not sufficient - the code quality is often not up-to par, there's no matching tests to show what has been fixed, or the fix is breaking backwards compatibility. I'd love to merge every contribution proposed for tedious, but if we'd just go and do that, we'd end up with a pretty broken library that will not work for anyone.

So, what's next? That depends on @tediousjs/tedious. I like the idea of merging this project with tedious. I don't care about name or credits, I do care about the result. I have no problem killing off this project if it makes sense and if there is an adequate replacement for it. And if I can help you with that, I'll be happy to. Until then, I'll do my best to keep node-mssql bugless and up-to-date.

I'd love to have the efforts of both projects combined, but just throwing everything together might not be the correct approach here. Maybe we should sit down and figure out what the best approach might look like?

Anyway, it's great to have you back! ❤️

[willmorgan]

@dhensby FYI

@patriksimek I've noted your comments here: https://github.com/tediousjs/node-mssql/issues/601#issuecomment-402854543

Dan and I are currently working, long term, on a platform that heavily leverages Azure/SQL Server on Azure, so there's an interest in us maintaining this library for as long as we're working on that platform. This library was chosen for most of the reasons you listed, plus pool management, plus it just does some things in an opinionated way so the team could get on with building the actual business logic, so it makes sense to take care of this.

Having taken OSS roles in previous companies that heavily used those projects, I've experienced the same reality as you when it comes to eventually moving on.

It's difficult to try and separate Tedious, the library that Microsoft docs recommend, and Tedious the OSS organisation - maybe it's not possible, so maybe it makes sense that MSFT allocates some permanent resource to maintaining this project? I agree that with such a popular project, we've got to be careful about sharing npm publish rights - both for code correctness and code security reasons.

From my point of view I'm willing to advocate spending some time during work hours (and spending _some_ time out of hours) to get this project in a better state - whether that's asking Microsoft to adopt or lend resource to this repo, or some light touch coordination to get more collaborators on board.

For things like Tedious version upgrades, I've been experimenting with a couple of other OSS repos with the concept of making things peerDependencies and inverting the control back to userland for providing the non-internal dependencies. This means that as soon as a new version of Tedious (the library) gets updated, there's no blocker on any contributor from upgrading on their own. Maybe that's something we could look at doing for an immediate v5 release? Tedious would remain a devDependency for referencing in tests, but wouldn't get installed when this library is included as a package dependency. Thoughts?

Btw, if you want a more in-depth discussion then it's my first name at my domain on email.

Thanks again for trusting us with the contributor rights, I hope we'll put them to good use!

[dhensby]

@willmorgan I don't know enough about npm's dependency resolution logic, but if our constraints are permissive enough (eg ^ not ~) shouldn't a project be able to declare a specific tedious version without marking it as a peerDependency?

[dhensby]

Also, I think this issue can be closed because it is now going to be maintained by people actively using it in production environments.

[willmorgan]

I don't know enough about npm's dependency resolution logic, but if our constraints are permissive enough (eg ^ not ~) shouldn't a project be able to declare a specific tedious version without marking it as a peerDependency?

It depends on your version of npm and whether any other packages you use require it. I've still not mastered npm-fu but my understanding is that it depends on your version of npm, and whether any other packages you use require it.

Couple of good reads:
https://docs.npmjs.com/files/package.json#peerdependencies
https://lexi-lambda.github.io/blog/2016/08/24/understanding-the-npm-dependency-model/
https://stackoverflow.com/a/34645112/127522

Also, I think this issue can be closed because it is now going to be maintained by people actively using it in production environments.

...for now! 😃