Sails SQL Adapter
THIS IS A WORK IN PROGRESS UNDER ACTIVE DEVELOPMENT - DO NOT USE IN PRODUCTION (targeting 2019 for the first stable release w/ 3 out of 5 dialects)
SQL adapter for Node.js/Sails and Waterline. Supports MySQL, PostgreSQL (PostgreSQL is under construction), and Microsoft SQL Server (MSSQL) databases.
This adapter is compatible with Node ≥8 and up. For SQL adapters compatible with older versions of Node.js, see legacy adapters sails-mysql and sails-postgresql.
Running the tests
Run the tests with the SAILS_SQL_TEST_1 environment variable set to the database connection URL of an empty/throwaway database you'd like to use for testing.
If you have more than one empty/throwaway database you'd like to test against, you can include multiple URLs to run the tests back to back:
For example:
SAILS_SQL_TEST_1='mssql://root:s3cr3td4nc3@127.0.0.1:8181/somethrowawaydb' SAILS_SQL_TEST_2='mysql://root:s3cr3td4nc3@127.0.0.1:3306/anotherthrowaway' npm testAcknowledgements
Thanks to dougwilson and felixge for all of their great work on mysql, @brianc for all of his fantastic work on the pg package, and thousands of contributors across the Node.js community that have made this level of simplicity and abstraction possible.
Help
For more examples, or if you get stuck or have questions, click here.
Bugs 
To report a bug, click here.
Contributing 
Please observe the guidelines and conventions laid out in the Sails project contribution guide when opening issues or submitting pull requests.
Other SQL databases
The eventual goal for this adapter is to support all of knex's supported databases, including SQLite and Oracle. (If you are using one of those databases for a real-world project, please contribute!)
License
MIT © 2018-present Mike McNeil
This package, like the Sails framework, is free and open-source under the MIT License.
Implementor notes (advanced)
About MySQL
Support for different types of managers is database-specific, and is not
built into the Waterline driver spec-- however this type of configurability
can be instrumented using meta.
In particular, support for ad-hoc connections (i.e. no pool) and clusters/multiple
pools (see "PoolCluster": https://github.com/felixge/node-mysql/blob/v2.10.2/Readme.md#poolcluster)
could be implemented here, using properties on meta to determine whether or not
to have this manager produce connections ad-hoc, from a pool, or from a cluster of pools.
Feel free to fork this driver and customize as you see fit. Also note that contributions to the core driver in this area are welcome and greatly appreciated!
Also note that if this driver is adapted to support managers which spawn ad-hoc connections or manage multiple pools/replicas using PoolCluster, then relevant settings would need to be included in the manager instance so that the manager could be appropriately destroyed here (in the case of ad-hoc connections, leased connections would need to be tracked on the manager, and then rounded up and disconnected here.)
For now, since we only support a single pool, we simply destroy it.
For more info, see https://github.com/felixge/node-mysql/blob/v2.10.2/Readme.md#closing-all-the-connections-in-a-pool
About getConnection()
Note that if this driver is adapted to support managers which spawn ad-hoc connections or manage multiple pools/replicas using PoolCluster, then relevant settings would need to be included in the manager instance so that connections can be appropriately fetched/opened here. For now, since we only support a single pool, we simply acquire a connection from the pool.
About releaseConnection()
Note that if this driver is adapted to support managers which spawn ad-hoc connections or manage multiple pools/replicas using PoolCluster, then relevant settings would need to be included in the manager instance so that connections can be appropriately released/destroyed in releaseConnection.
For now, since we only support a single pool, we simply release the connection back to the pool. And if the connection cannot be released back to the pool gracefully, we try to force it to disconnect.
If releaseConnection() succeeds, then we were either able to release the connection gracefully (i.e. worked on the first try), or that we had to try again, forcibly destroying the connection.