I don't write for Node nor SQL Server, but that connection string looks gnarly. Is there a reason for not using a plain object that could then be merged with a set of internal defaults, then serialized from there? Ruby uses this pattern often, it's very clean and idiomatic.
For some reason the driver also requires Visual C++ 2010 as well as SQL Server Native Client 11.0, and includes significant C++ boilerplate which was clearly pasted verbatim from existing C++ codebases, thus ensuring the driver is beyond modification and customization for the typical Node dev.
> The Microsoft Driver for Node.JS for SQL Server is hosted on Github, accentuating our continued involvement with the Open Source community.
Except, this isn't so much openness as it is an underhanded attempt at migrating more developers to their proprietary platforms. It certainly makes business sense for them and I'm not going to make any normative claims, but I wish they wouldn't beat around the bush. The "Open Source" community that they're trying to cater to is more bullshit-averse than they seem to realize.
> Except, this isn't so much openness as it is an underhanded attempt at migrating more developers to their proprietary platforms.
Shame on them. They shouldn't be contributing software at all if it won't work on every platform. For all they know, I might want to connect to SQL Server from Node.JS running on my Commodore 64, but they don't provide the native code compiled for the 6510.
Is there a name given to your type of argument? The idea is to simply reply with an an absurd extreme counter example. People use it all the time. Perhaps it's some sort of extrapolation argument?
Reductio Ad Absurdum (e.g. "for Microsoft to support anyone but themselves they thus must support every fringe platform, including those popular twenty years ago"). It's a particularly boring tactic of response and never adds anything to the conversation.
You seem to be looking at this from only your narrow perspective of your own development and hosting environment.
There are a whole bunch of places with mixed environment where this is extremely useful and can get Node.js approved for use by management who don't want to deal with the headaches of managing, hosting, securing and administering yet another database server like MySQL or PostgreSQL when they already do that for SQL Server and want to run Node on Windows to avoid having to deal with another OS like Linux.
>Except, this isn't so much openness as it is an underhanded attempt at migrating more developers to their proprietary platforms
In these cases, aren't they helping Node get a toe in the door which can lead to further Open Source usage(which in some cases can lead to ditching of SQL Server and going to MySQL or PostgreSQL to save on licensing)?
>but I wish they wouldn't beat around the bush. The "Open Source" community that they're trying to cater to is more bullshit-averse than they seem to realize.
Your comment comes off as incredibly short sighted and negative. If it doesn't work for you, just move on. Where's the beating around the bush? I don't see any claims on the linked blog that they're doing this for openness. Slagging on them for making things more compatible doesn't make sense. If they make it compatible with Linux, some people will say "they're trying to sell their stuff on Linux, it's on FOSS". I think some people will only be happy with open sourcing SQL Server and making it absolutely free which will make them lose 95% of their revenue and I am glad Microsoft is not looking at catering to RMS.
it does make sense. The connection string is passed to the underlying SQL client as is.
That means that you don't have to update the node driver code as well as SQL client if they change the connection string capabilities or SQL client version on the PC.
I agree - the connection string does look ugly and isn't very node-like, but you don't have to write it that often. It's also the standard for connection strings as mentioned by others, so other Windows/Microsoft devs will find it familiar.
The big deal about all of this is that Node.js can now connect to SQL Server, through a Microsoft developed module. For anyone working at a company that is a Microsoft-based shop (like myself), this is big step to getting to use Node.js at work.
Regarding being Windows only, if an enterprise is running SQL Server, they are probably running Windows enterprise wide, or have at lease a couple application servers running windows. I don't think it is that harsh of a limitation.
I was expecting to see that someone ported jTDS (http://jtds.sourceforge.net/) to JavaScript. I have zero idea if something like Emscripten could be used for an effort like that, nor if it would be performant enough for use in a database scenario, but I think a pure JavaScript library would probably be useful to a wider audience.
22 comments
[ 2.8 ms ] story [ 53.5 ms ] threadIt does look rather gnarly but if you work with it for a bit, you will find that connection strings are incredibly powerful.
Also
really should be:> The Microsoft Driver for Node.JS for SQL Server is hosted on Github, accentuating our continued involvement with the Open Source community.
Except, this isn't so much openness as it is an underhanded attempt at migrating more developers to their proprietary platforms. It certainly makes business sense for them and I'm not going to make any normative claims, but I wish they wouldn't beat around the bush. The "Open Source" community that they're trying to cater to is more bullshit-averse than they seem to realize.
Shame on them. They shouldn't be contributing software at all if it won't work on every platform. For all they know, I might want to connect to SQL Server from Node.JS running on my Commodore 64, but they don't provide the native code compiled for the 6510.
There are a whole bunch of places with mixed environment where this is extremely useful and can get Node.js approved for use by management who don't want to deal with the headaches of managing, hosting, securing and administering yet another database server like MySQL or PostgreSQL when they already do that for SQL Server and want to run Node on Windows to avoid having to deal with another OS like Linux.
>Except, this isn't so much openness as it is an underhanded attempt at migrating more developers to their proprietary platforms
In these cases, aren't they helping Node get a toe in the door which can lead to further Open Source usage(which in some cases can lead to ditching of SQL Server and going to MySQL or PostgreSQL to save on licensing)?
>but I wish they wouldn't beat around the bush. The "Open Source" community that they're trying to cater to is more bullshit-averse than they seem to realize.
Your comment comes off as incredibly short sighted and negative. If it doesn't work for you, just move on. Where's the beating around the bush? I don't see any claims on the linked blog that they're doing this for openness. Slagging on them for making things more compatible doesn't make sense. If they make it compatible with Linux, some people will say "they're trying to sell their stuff on Linux, it's on FOSS". I think some people will only be happy with open sourcing SQL Server and making it absolutely free which will make them lose 95% of their revenue and I am glad Microsoft is not looking at catering to RMS.
Presumably because it links to some native client dll which is built for Windows?
I could be wrong but it doesn't look like a licensing restriction - it's more of a technical limitation.
In my opinion it was very lazy for them to not alter it in this use case. It doesn't make much sense.
That means that you don't have to update the node driver code as well as SQL client if they change the connection string capabilities or SQL client version on the PC.
The big deal about all of this is that Node.js can now connect to SQL Server, through a Microsoft developed module. For anyone working at a company that is a Microsoft-based shop (like myself), this is big step to getting to use Node.js at work.
Regarding being Windows only, if an enterprise is running SQL Server, they are probably running Windows enterprise wide, or have at lease a couple application servers running windows. I don't think it is that harsh of a limitation.
Cheers,
It's not native SQL server, but does the job.
[Disclaimer: I'm the author.]
Please feel free to let us know what you believe is a good approach!
https://github.com/WindowsAzure/node-sqlserver/issues/17
Thanks,
Jonathan @kop48