Skip to content
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

Self managed connections #187

Open
bhirsz opened this issue Oct 30, 2023 · 5 comments
Open

Self managed connections #187

bhirsz opened this issue Oct 30, 2023 · 5 comments

Comments

@bhirsz
Copy link
Member

bhirsz commented Oct 30, 2023

One of the major problems with using libraries like DatabaseLibrary is managing the connection. If we implement #149, it could cause additional problems. Typically QA need to implement following logic:

Connect To Database  (...)
Query
[Teardown]    Disconnect Connection

But often Disconnect Connection is not in teardown (so the connection can remain open after test fails), we could several long running connections even if we're not querying for anything. For that reason we could add optional option for 'self managed connection' - in short, we could open and close connection each time we perform an query.

The default behaviour of the library will not change, it will be only extra option that will open/close connection if it doesn't exist.

*** Settings ***
Library    DatabaseLibrary    auto_connect=${True}
Suite Setup    Configure Connection    ${params}  # need to configure default connection

*** Test Cases ***
Test 1
    Query    SELECT * FROM table1  # will open and close connection on its own

Test 2
    Query    SELECT * FROM table2  # will open and close connection on its own
@amochin
Copy link
Collaborator

amochin commented Nov 5, 2023

This is a great idea!
We could also consider setting the connection details as library input params.

@wvanmourik-aa
Copy link

wvanmourik-aa commented Dec 11, 2023

+1

For our use case, the database(s) is what we are testing and it makes little sense to open and close connections per query or statement. Instead, we want the connection to stay open until the entire test has been completed; encompassing multiple queries/statements.

So for us, the new logged warnings for reusing connections are an annoyance in the test reports.

(We do have the close connection call in the teardown still, regardless.)

@bhirsz
Copy link
Member Author

bhirsz commented Dec 11, 2023

+1

For our use case, the database(s) is what we are testing and it makes little sense to open and close connections per query or statement. Instead, we want the connection to stay open until the entire test has been completed; encompassing multiple queries/statements.

So for us, the new logged warnings for reusing connections are an annoyance in the test reports.

(We do have the close connection call in the teardown still, regardless.)

Looking at implementation, you should only receive reusing connection if you're trying to open connection without closing previous one. For your case we could add more control over what happens in such case:

Connect To Database    &{params}    alias=conn1
Connect To Database    &{params}    alias=conn1
  1. By default, warn you're overwriting open connection but proceed with it (as it is now)
  2. Add flag to optionally disable warning from 1)
  3. Add flag to automatically close previous connection (in this case conn1 will be closed and new connection will be open)
  4. Add flag to not open connection if there is connection with given alias

It could done using one variable, ie if_conn_exist = "log:warn,old:ignore,new:open", "log:ignore,old:close,new:open", "log:warn:old:ignore,new:ignore" - but I need to think on how to make it more user friendly.. .

@bhirsz
Copy link
Member Author

bhirsz commented Dec 11, 2023

Also, from self managed connection perspective, the goal was to create short lived connections. But in your case it could be extended to allow long lived connection - configure connection when importing library and whener it's necessary it will be opened automatically and remain open till the library is deleted (when tests are finished) or disconnect is called manually.

@wvanmourik-aa
Copy link

Option 4 would be excellent for our use-case; if there already is a connection, then (re)use it.

@amochin amochin added this to the next_version milestone Aug 15, 2024
@amochin amochin removed this from the 2.0.0 milestone Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants