Support for AS5 databases

[albireox]

• More robustly supports using postgresql:// URIs for connection, including parsing the URI and extracting connection parameters.
• Supports connecting to the PostgreSQL database using a socket connection instead of TCP/IP.
• Type all connection methods and attributes.
• Streamline the connection logic without (I think) changes to its current behaviour.
• Deprecate connect_from_parameters in favour of connect.

[codecov]

Codecov Report

❌ Patch coverage is 61.01695% with 69 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.54%. Comparing base (040488f) to head (2124184).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
python/sdssdb/connection.py	61.01%	41 Missing and 28 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #325      +/-   ##
==========================================
- Coverage   89.54%   89.54%   -0.01%     
==========================================
  Files          46       46              
  Lines       26812    26832      +20     
  Branches      478      490      +12     
==========================================
+ Hits        24010    24026      +16     
+ Misses       2765     2755      -10     
- Partials       37       51      +14     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[havok2063]

ValueError?

[havok2063]

They are a few asserts in here. Can we raise an error instead? Maybe a ValueError or TypeError here?

[havok2063]

With the connection streamlining, and socket stuff, what is the current precedence order for connecting? And preferred method? We may want to do a pass on the docs.

[albireox]

I have been trying to not change the user-facing behaviour as I streamline, but that should be checked, and I'm in the process of adding tests. One thing that's still there because I didn't want to break it (but may be worth discussing) is that one can override a loaded profile by passing arguments to connect(), for example one can do set_profile('utah_tunnel') and then connect(port=11111) which will connect on localhost, with user sdss_user but with port 11111 instead of the profile 7502. That's convenient but it may be confusing, so it may be worth discussing if we want to always have to specify a full set of arguments.

By default use_socket=False which is the current behaviour, so that should also not change. Currently we don't have an easy way to connect on a socket if the database server doesn't have the loopback connection properly set up, which is not especially uncommon.

[havok2063]

I was wondering if we were planning on keeping the profiles around. I think it can be confusing as to if one needs a profile or not to use sdssdb. Admittedly I don't really use profiles but also just noticed there is a tunnel_pipelines that I could have been using. I do kind of like the ability to use a profile but optionally change one or more parameters. If we're always specifying the full set of parameters on connect then do we need the profiles?

I think it's good we're simplifying the connection, with connect as the primary entry point. It should be flexible enough to connect to a uri, a profile, a dict of connection params, etc.

[johndonor3]

Profiles make a lot of operationns software MUCH easier. Jose and I both have code that needs to run at both observatories and at Utah, so setting the database connection in the background based on FQDN is quite convenient.

Although, it can be a bit unwieldy at Utah since they change the hostnames all the time, and there isn't necessarily a consistent naming convention across nodes. I was actually considering asking y'all if we could set Utah (i.e. operations) as the default profile if the regex doesn't find anything? Feels like it wouldn't affect most people if they're setting connections manually, but it'd help me whip some inherited software into shape much more quickly.

[albireox]

I like the ability of setting a profile, and it's nice that in "most" situations sdssdb just connects to the database with the right connection. But then I'm also not sure how often that would just work fine without profiles since we normally connect to localhost. I lean towards leaving the profiles, but it can also be confusing mixing profiles with override parameters, and maybe there is a better way to handle those. One thing I added in this streamlining is a more verbose warning when the connection fails that outputs the connection parameters used; I have found myself very confused a number of times trying to figure out why a connection was failing and what sdssdb was trying to do.