4 ms·
I wish there was a library for "every" that took a standardized connection string and mapped it to "every" DB/storage/queue/etc client. This is one of those thi
by gravypod 5y ago
I wish there was a library for "every" that took a standardized connection string and mapped it to "every" DB/storage/queue/etc client. This is one of those things that should be a solved problem that we as an industry should just move past having to deal with.
This would obviously be too much effort to actually do but it would save a lot of headache. "We can't X because we cant pass it's config to the software"
- laurent92 5y agoOr “we had to restart 7 times because I thought I knew the syntax, but it didn’t seem taken into account, so I changed it 6 more times and actually the second time was correct but needed a second parameter.”
- jolux 5y ago> I wish there was a library for "every" that took a standardized connection string and mapped it to "every" DB/storage/queue/etc client. This has been around for like 30 years, it's called ODBC. As long as you're using an ODBC driver the strings are the same (modulo the driver specification).
- zo1 5y agoIntuitively you would think so, but unfortunately not. The ODBC specification last time I looked into it doesn't dictate the key-values that is given to the database driver so it's up to each driver to pick it's own. E.g. HOSTNAME vs SERVER, or PASSWORD vs PWD are the two main differences I recall. I'm not super well-versed in it, so I'm sure someone else here can provide more detail as to why it's different or if there is history behind it being like this. But from a dev's perspective, ODBC connection strings are an absolute mess. Not to mention no one really knows what's what, hence this website. Fun fact, I tried to find the spec as part of responding here and I couldn't find it. Best I could find was this: https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/driver-manager-s-role-in-the-connection-process?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/odbc/reference/develop-... But you go around finding actual details and next thing you know it's under the heading of "SQL Server XXXX" so you have no idea if it's the "spec" or just the MS SQL Server driver reference.
- jolux 5y agoThat’s a shame. I never dug deep into this, but I’m pretty sure the Postgres and SQL Server strings are similar.
- marcosdumay 5y agoHum... Oracle has its service names and SID, MS SQL server has instances, PostgreSQL is actually what you'd expect from a network server, SQLite is obviously completely different from anything else. I don't remember the MySQL connection parameters, but I remember the username is a crazy multi-part string. And that's just the basic connection parameters, you will want to set some advanced ones once in a while. I don't see what you gain by creating an universal interface, since they are all completely different from each other.
- gravypod 5y agoUsing a schema that allows you to specify a different parser for the remainder of the string would fix this. Like: sqlite:// and redis://. You could the have standards for common things like usernames, passwords, hosts, ports, and storage path.
- shireboy 5y agoIn my experience, while it sounds nice to be able to swap out databases with just a config change, it really takes code changes even with an ORM. I recently wrote an app that can use either SQLlite or MS SQL with EF Core. Many things are the same, but there are some queries that I have to handle differently between providers. If I were to add mongo or similar I’d definitely have more changes. I do choose the provider based on the connection string though :)
- gravypod 5y agoThis is not a swap out DBs thing. This is a "have the ability to tweak all of the config options from a connection string with no code changes" You'd still get the correct client for your DB. You'd just not need to plan ahead to accept parameters.