-
Notifications
You must be signed in to change notification settings - Fork 2
No exception when trying to connect to server #218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @shraik, thank you for writing in. It looks like the code correctly raises exceptions as displayed in your output? ConnectionRefusedError: [WinError 10061] Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение sqlalchemy.exc.OperationalError: (crate.client.exceptions.ConnectionError) No more Servers available, exception from last server: HTTPConnectionPool(host='crate.airflow.local', port=4201): Max retries exceeded with url: /_sql?types=true (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x000001D93D34D260>: Failed to establish a new connection: [WinError 10061] Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение')) With kind regards, |
let me clarify my question. I took this article as an example and expected similar behavior: the output "success connect to DB" shows that the exception was not thrown when The error you specified, ConnectionRefusedError, is thrown when executing the line from the example above. Maybe my example was not very indicative. Let's adjust it like this. The output will remain unchanged.
|
Dear @shraik, thanks for your report. We are able to confirm the behaviour your are observing. Contrary to that, other than a deviating TCP connection handling, when connecting to an instance of PostgreSQL per SET datestyle TO 'ISO' SELECT t.oid,
typarray
FROM pg_type t
JOIN pg_namespace ns ON typnamespace = ns.oid
WHERE typname = 'hstore'; In the case of CrateDB, no SQL commands are emitted, and the connection is HTTP-based, so it apparently only fails when actually trying to invoke SQL statements, and not on I think the situation should be improved by actually emitting a (dummy) SQL statement, to make the connection fail likewise on With kind regards, |
Hi again, we found the deviation is already originating at the lower level DBAPI driver, so we submitted a corresponding improvement to that project. With kind regards, |
Dear @shraik, your issue may have been solved by recent improvements to the Python driver. We just published a pre-release package 2.1.0.dev0, see also crate/crate-python#711 (comment). Because sqlalchemy-cratedb uses a version constraint for this package like For example, because you are currently also using a pre-release of the SQLAlchemy dialect, use this command to install both packages: uv pip install --upgrade 'crate>=2.1.0.dev0' 'sqlalchemy-cratedb>=0.42.0.dev2' With kind regards, |
Great! The exception is thrown correctly. But there is one nuance, can you check the operation of the "timeout" parameter? engine = sa.create_engine(cons, echo=False) => engine = sa.create_engine(cons, echo=False, connect_args={"timeout": 1}) => engine = sa.create_engine(cons, echo=False, connect_args={"timeout": 2})
|
This comment has been minimized.
This comment has been minimized.
Hi again.
Thanks for your feedback!
I've created a dedicated ticket about your other question. |
No exception thrown when trying to connect to obviously invalid address.
How to check that the server is available?
Test example:
Out:
The text was updated successfully, but these errors were encountered: