diff --git a/.github/styles/config/vocabularies/Aurora/accept.txt b/.github/styles/config/vocabularies/Aurora/accept.txt
index df4ac5d5..d2cb6329 100644
--- a/.github/styles/config/vocabularies/Aurora/accept.txt
+++ b/.github/styles/config/vocabularies/Aurora/accept.txt
@@ -13,3 +13,5 @@ autocommit
hostname
[Kk]eepalive
[Bb]ackoff
+[Xx]ray
+[Cc]loudwatch
diff --git a/.github/workflows/integration_tests.yml b/.github/workflows/integration_tests.yml
index 5e7de0e6..054102b9 100644
--- a/.github/workflows/integration_tests.yml
+++ b/.github/workflows/integration_tests.yml
@@ -15,6 +15,7 @@ jobs:
matrix:
python-version: [ "3.8", "3.11" ]
engine_version: ["lts", "latest"]
+ environment: ["mysql", "pg"]
steps:
- name: 'Clone repository'
@@ -59,15 +60,13 @@ jobs:
- name: 'Run Integration Tests'
run: |
- ./gradlew --no-parallel --no-daemon test-python-${{ matrix.python-version }} --info
+ ./gradlew --no-parallel --no-daemon test-python-${{ matrix.python-version }}-${{ matrix.environment }} --info
env:
RDS_CLUSTER_DOMAIN: ${{ secrets.DB_CONN_SUFFIX }}
RDS_DB_REGION: ${{ secrets.AWS_DEFAULT_REGION }}
AWS_ACCESS_KEY_ID: ${{ env.TEMP_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ env.TEMP_AWS_SECRET_ACCESS_KEY }}
AWS_SESSION_TOKEN: ${{ env.TEMP_AWS_SESSION_TOKEN }}
- AURORA_MYSQL_DB_ENGINE_VERSION: ${{ secrets.engine_version }}
- AURORA_PG_ENGINE_VERSION: ${{ matrix.engine_version }}
- name: 'Archive results'
if: always()
diff --git a/.github/workflows/integration_tests_codebuild.yml b/.github/workflows/integration_tests_codebuild.yml
index 1a9bdcbd..59415388 100644
--- a/.github/workflows/integration_tests_codebuild.yml
+++ b/.github/workflows/integration_tests_codebuild.yml
@@ -11,7 +11,6 @@ jobs:
matrix:
python-version: [ "3.8", "3.11" ]
environment: [ "mysql", "pg" ]
- engine_version: ["latest"]
runs-on: ubuntu-latest
environment: ${{ matrix.environment }}_integ
@@ -67,13 +66,13 @@ jobs:
AWS_SECRET_ACCESS_KEY: ${{ env.TEMP_AWS_SECRET_ACCESS_KEY }}
AWS_SESSION_TOKEN: ${{ env.TEMP_AWS_SESSION_TOKEN }}
RDS_ENDPOINT: ${{ secrets.RDS_ENDPOINT }}
- AURORA_MYSQL_DB_ENGINE_VERSION: ${{ secrets.engine_version }}
- AURORA_PG_ENGINE_VERSION: ${{ matrix.engine_version }}
+ AURORA_MYSQL_DB_ENGINE_VERSION: "latest"
+ AURORA_PG_ENGINE_VERSION: "latest"
- name: 'Archive results'
if: always()
uses: actions/upload-artifact@v3
with:
- name: pytest-integration-report-${{ matrix.environment }}
+ name: pytest-integration-report
path: ./tests/integration/container/reports
retention-days: 5
diff --git a/README.md b/README.md
index cf26b232..c6c9f97c 100644
--- a/README.md
+++ b/README.md
@@ -139,7 +139,7 @@ The following table lists the connection properties used with the AWS Advanced P
### Using the AWS Advanced Python Driver
Technical documentation regarding the functionality of the AWS Advanced Python Driver will be maintained in this GitHub repository. Since the AWS Advanced Python Driver requires an underlying Python driver, please refer to the individual driver's documentation for driver-specific information.
-To find all the documentation and concrete examples on how to use the AWS Advanced Python Driver, please refer to the [AWS Advanced Python Driver Documentation](./docs/Documentation.md) page.
+To find all the documentation and concrete examples on how to use the AWS Advanced Python Driver, please refer to the [AWS Advanced Python Driver Documentation](./docs/README) page.
### Known Limitations
@@ -196,6 +196,7 @@ For all other questions, please use [GitHub discussions](https://github.com/awsl
3. Make any changes on your fork. Make sure you are aware of the requirements for the project (e.g. do not require Python 3.7 if we are supporting Python 3.8 and higher).
4. Create a pull request from your fork.
5. Pull requests need to be approved and merged by maintainers into the main branch.
+
> [!NOTE]\
> Before making a pull request, [run all tests](./docs/development-guide/DevelopmentGuide.md#running-the-tests) and verify everything is passing.
@@ -213,7 +214,7 @@ This `aws-advanced-python-wrapper` is being tested against the following Communi
| Database | Versions |
|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| MySQL | 8.0.32 |
+| MySQL | 8.3.0 |
| PostgreSQL | 15.2 |
| Aurora MySQL | MySQL 8.0.mysql_aurora.3.02.2 (Wire-compatible with MySQL 8.0.23 onward. For more details see [here](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.3022.html)) |
| Aurora PostgreSQL | 14.7 and 15.2 (Compatible with PostgreSQL 14.7 and 15.2, see release notes [here](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html)) |
diff --git a/docs/GettingStarted.md b/docs/GettingStarted.md
index 303456df..d352f52e 100644
--- a/docs/GettingStarted.md
+++ b/docs/GettingStarted.md
@@ -9,10 +9,13 @@ Before using the AWS Advanced Python Driver, you must install:
- Your choice of underlying Python driver.
- To use the wrapper with Aurora with PostgreSQL compatibility, install [Psycopg](https://github.com/psycopg/psycopg).
- To use the wrapper with Aurora with MySQL compatibility, install [MySQL Connector/Python](https://github.com/mysql/mysql-connector-python).
+> [!NOTE]\
+> The driver has been verified on Psycopg 3.1.12+ and MySQL Connector/Python 8.1.0+. Compatibility with prior versions have not been tested.
## Obtaining the AWS Advanced Python Driver
You can install the AWS Advanced Python Driver and the underlying Python drivers via [pip](https://pip.pypa.io/en/stable/).
+The order of installation does not matter.
To use the AWS Advanced Python Driver with Psycopg for Aurora PostgreSQL, run:
@@ -39,10 +42,23 @@ awsconn = AwsWrapperConnection.connect(
Connection.connect,
"host=database.cluster-xyz.us-east-1.rds.amazonaws.com dbname=db user=john password=pwd",
plugins="failover",
- wrapper_dialect="aurora-pg",
autocommit=True
)
```
+
+Similarly, to start using the driver with MySQL Connector/Python, you need to pass the connect function to the `AwsWrapperConnection#connect` method as shown in the following example:
+```python
+awsconn = AwsWrapperConnection.connect(
+ mysql.connector.Connect,
+ host="database.cluster-xyz.us-east-1.rds.amazonaws.com",
+ database="mysql",
+ user="admin",
+ password="pwd",
+ plugins="failover",
+ autocommit=True
+)
+```
+
The `AwsWrapperConnection#connect` method accepts the connection configuration through both the connection string and the keyword arguments.
You can either pass the connection configuration entirely through the connection string, entirely though the keyword arguments, or through both the connection string and the keywords arguments as shown below.
diff --git a/docs/Documentation.md b/docs/README.md
similarity index 100%
rename from docs/Documentation.md
rename to docs/README.md
diff --git a/docs/development-guide/Architecture.md b/docs/development-guide/Architecture.md
index 055e78c1..98d8c543 100644
--- a/docs/development-guide/Architecture.md
+++ b/docs/development-guide/Architecture.md
@@ -23,4 +23,4 @@ During execution, plugins may utilize the plugin service to help its execution b
> - plugin service
> - loaded plugin classes
> - Multiple Python Connection objects opened to the same database server will have separate sets of instances mentioned above.
-> - All plugins share the same instance of plugin service and the same instance of host list provider.
\ No newline at end of file
+> - All plugins share the same instance of plugin service and the same instance of host list provider.
diff --git a/docs/development-guide/DevelopmentGuide.md b/docs/development-guide/DevelopmentGuide.md
index 84433d3a..2f7d3275 100644
--- a/docs/development-guide/DevelopmentGuide.md
+++ b/docs/development-guide/DevelopmentGuide.md
@@ -15,21 +15,21 @@ You can now make changes in the repository.
The AWS Advanced Python Driver uses the following tests to verify its correctness:
-| Tests | Description |
-|-----------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Unit tests | Tests for AWS Advanced Python Driver correctness. |
-| Failover integration tests | Driver-specific tests for different reader and writer failover workflows using the Failover Connection Plugin. |
-| Enhanced failure monitoring integration tests | Driver-specific tests for the enhanced failure monitoring functionality using the Host Monitoring Connection Plugin. |
-| AWS authentication integration tests | Driver-specific tests for AWS authentication methods with the AWS Secrets Manager Plugin or the AWS IAM Authentication Plugin. |
+| Tests | Description |
+|-----------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------|
+| Unit tests | Tests for AWS Advanced Python Driver correctness. |
+| Failover integration tests | Driver-specific tests for different reader and writer failover workflows using the Failover Connection Plugin. |
+| Enhanced failure monitoring integration tests | Driver-specific tests for the enhanced failure monitoring functionality using the Host Monitoring Connection Plugin. |
+| AWS authentication integration tests | Driver-specific tests for AWS authentication methods with the AWS Secrets Manager Plugin or the AWS IAM Authentication Plugin. |
### Performance Tests
The AWS Advanced Python Driver has the following tests to verify its performance:
-| Tests | Description |
-|-----------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Connection plugin manager benchmarks | The [benchmarks](../../benchmarks/README.md) subproject measures the overhead from executing Python method calls with multiple connection plugins enabled. |
-| Manually-triggered performance tests | The [failover plugin performance tests](../../tests/integration/container/test_failover_performance.py) and [enhanced failure monitoring performance tests](../..tests/integration/container/test_read_write_splitting_performance.py) measure the plugins' performance under different configurations |
+| Tests | Description |
+|--------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Connection plugin manager benchmarks | The [benchmarks](../../benchmarks/README.md) subproject measures the overhead from executing Python method calls with multiple connection plugins enabled. |
+| Manually-triggered performance tests | The [failover plugin performance tests](../../tests/integration/container/test_failover_performance.py) and [enhanced failure monitoring performance tests](../..tests/integration/container/test_read_write_splitting_performance.py) measure the plugins' performance under different configurations |
### Running the Tests
diff --git a/docs/development-guide/IntegrationTests.md b/docs/development-guide/IntegrationTests.md
index 31d86be4..5dca571c 100644
--- a/docs/development-guide/IntegrationTests.md
+++ b/docs/development-guide/IntegrationTests.md
@@ -19,10 +19,10 @@ This documentation walks through the requirements and steps required to run and
### Aurora Test Requirements
- An AWS account with:
- - RDS permissions
+ - RDS permissions.
- EC2 permissions so integration tests can add the current IP address in the Aurora cluster's EC2 security group.
- - For more information,
- see: [Setting Up for Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SettingUp.html).
+ - XRay and Cloudwatch permissions for the integration tests to report telemetries.
+ - For more information, see: [Setting Up for Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SettingUp.html).
## Recommendations for ease of use
@@ -85,7 +85,7 @@ unset FILTER # Done testing the IAM tests, unset FILTER
Remote path: `/app`
- 6. Click OK, Apply, OK.
+ 4. Click OK, Apply, OK.
3. At the top right of the Pycharm window, click the dropdown arrow and select your newly created debug configuration
4. Click the bug symbol to start the debug configuration. Pycharm will begin listening for a debug connection
5. Navigate to your Pycharm git bash terminal. In the terminal, navigate to the project root directory. Execute a gradle
diff --git a/docs/development-guide/PluginService.md b/docs/development-guide/PluginService.md
index 28807e88..fce76c2b 100644
--- a/docs/development-guide/PluginService.md
+++ b/docs/development-guide/PluginService.md
@@ -1,4 +1,4 @@
-## Plugin Service
+# Plugin Service

diff --git a/docs/using-the-python-driver/DatabaseDialects.md b/docs/using-the-python-driver/DatabaseDialects.md
index f634ad6a..cd5e15ea 100644
--- a/docs/using-the-python-driver/DatabaseDialects.md
+++ b/docs/using-the-python-driver/DatabaseDialects.md
@@ -44,4 +44,4 @@ Once the custom dialect class has been created, tell the AWS Advanced Python Dri
```python
custom_dialect: Dialect = CustomDialect()
DialectManager.custom_dialect = custom_dialect
-```
\ No newline at end of file
+```
diff --git a/docs/using-the-python-driver/DriverDialects.md b/docs/using-the-python-driver/DriverDialects.md
index 42a3f0ba..f0f4d1c7 100644
--- a/docs/using-the-python-driver/DriverDialects.md
+++ b/docs/using-the-python-driver/DriverDialects.md
@@ -18,7 +18,6 @@ By default, the driver dialect is determined based on the Connection function pa
>
> The `wrapper_driver_dialect` parameter is not required. When it is not provided by the user, the AWS Advanced Python Driver will determine which of the existing target driver dialects to use based on the Connect function passed to the driver. If target driver specific implementation is not found, the AWS Advanced Python Driver will use a generic target driver dialect.
-
### List of Available Driver Codes
Driver Dialect codes specify which driver dialect class to use.
diff --git a/docs/using-the-python-driver/HostAvailabilityStrategy.md b/docs/using-the-python-driver/HostAvailabilityStrategy.md
index 50a2250d..b7dc129f 100644
--- a/docs/using-the-python-driver/HostAvailabilityStrategy.md
+++ b/docs/using-the-python-driver/HostAvailabilityStrategy.md
@@ -8,17 +8,17 @@ When database hosts fail, they are marked as `NOT_AVAILABLE` and will not be che
Different strategies can be swapped out for different behaviors. The default Host Availability Strategy the driver uses can be configured as specified in the [configuration parameters table](#configuration-parameters).
## Configuration Parameters
-| Parameter | Value | Required | Description | Default Value |
-|----------------------------------------------|-----------|----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------|
+| Parameter | Value | Required | Description | Default Value |
+|---------------------------------------------------|-----------|----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------|
| `default_host_availability_strategy` | `String` | No | This overrides the driver's default host availability strategy. Possible values are listed in the [Host Availability Strategies](#host-availability-strategies) section. | `None` |
-| `host_availability_strategy_max_retries` | `Integer` | No | Maximum number of times a host availability strategy will retry a host that is not available. | `5` |
-| `host_availability_strategy_initial_backoff_time` | `Integer` | No | The initial wait time in seconds. This parameter is only applicable for host availability strategies employing a time-based backoff. | `30` |
+| `host_availability_strategy_max_retries` | `Integer` | No | Maximum number of times a host availability strategy will retry a host that is not available. | `5` |
+| `host_availability_strategy_initial_backoff_time` | `Integer` | No | The initial wait time in seconds. This parameter is only applicable for host availability strategies employing a time-based backoff. | `30` |
## Host Availability Strategies
These are different host availability strategies to choose from when specifying the `default_host_availability_strategy` parameter value.
-| Name | Value | Description |
-|------------------------------------------------|----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Name | Value | Description |
+|------------------------------------------------|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Exponential Backoff Host Availability Strategy | `exponential_backoff` | This strategy does not actively health check hosts and instead allows host availability consumers to perform health checks.
If a host is marked `NOT_AVAILABLE`, there is a backoff time period where the host's availability will be `NOT_AVAILABLE`. After the backoff period, the host's availability will be `AVAILABLE` so that host availability consumers can attempt to connect to the host.
Each subsequent time the host fails a health check, the host is set to `NOT_AVAILABLE` and another backoff period twice the duration of the last will occur before the host availability is set to `AVAILABLE` again. However, if the host passes the health check, consumers will set the host availability to `AVAILABLE` with no backoff period. The next backoff period that occurs will be reset to the initial backoff time.
The backoff time period can be set in seconds using the `host_availability_strategy_initial_backoff_time` configuration parameter. |
If `default_host_availability_strategy` is not specified, the default strategy will be a simple pass through strategy. No extra logic or functionality will be added when host availability is set or fetched.
diff --git a/docs/using-the-python-driver/UsingThePythonDriver.md b/docs/using-the-python-driver/UsingThePythonDriver.md
index 112d5d4c..043d7eb5 100644
--- a/docs/using-the-python-driver/UsingThePythonDriver.md
+++ b/docs/using-the-python-driver/UsingThePythonDriver.md
@@ -1,7 +1,7 @@
# Using the AWS Advanced Python Driver
The AWS Advanced Python Driver leverages community Python drivers and enables support of AWS and Aurora functionalities.
-Currently, [Psycopg](https://github.com/psycopg/psycopg) and [MySQL Connector/Python](https://github.com/mysql/mysql-connector-python) are supported.
+Currently, [Psycopg](https://github.com/psycopg/psycopg) 3.1.12+ and [MySQL Connector/Python](https://github.com/mysql/mysql-connector-python) 8.1.0+ are supported. Compatibility with prior versions of these drivers has not been tested.
## Using the AWS Advanced Python Driver with plain RDS databases
@@ -71,7 +71,7 @@ The AWS Advanced Python Driver has several built-in plugins that are available t
| Aurora Stale DNS Plugin | `stale_dns` | Aurora | Prevents incorrectly opening a new connection to an old writer host when DNS records have not yet updated after a recent failover event.
:warning:**Note:** Contrary to `failover` plugin, `stale_dns` plugin doesn't implement failover support itself. It helps to eliminate opening wrong connections to an old writer host after cluster failover is completed.
:warning:**Note:** This logic is already included in `failover` plugin so you can omit using both plugins at the same time. | None |
| [Aurora Connection Tracker Plugin](./using-plugins/UsingTheAuroraConnectionTrackerPlugin.md) | `aurora_connection_tracker` | Aurora | Tracks all the opened connections. In the event of a cluster failover, the plugin will close all the impacted connections to the host. This plugin is enabled by default. | None |
| [Read Write Splitting Plugin](./using-plugins/UsingTheReadWriteSplittingPlugin.md) | `read_write_splitting` | Aurora | Enables read write splitting functionality where users can switch between database reader and writer instances. | None |
-| [Fastest Response Strategy Plugin](./using-plugins/UsingTheFastestResponseStrategyPlugin.md) | `fastest_response_strategy` | Aurora | A host selection strategy plugin that uses a host monitoring service to monitor each reader host's response time and choose the host with the fastest response. | None |
+| [Fastest Response Strategy Plugin](./using-plugins/UsingTheFastestResponseStrategyPlugin.md) | `fastest_response_strategy` | Aurora | A host selection strategy plugin that uses a host monitoring service to monitor each reader host's response time and choose the host with the fastest response. | None |
In addition to the built-in plugins, you can also create custom plugins more suitable for your needs.
For more information, see [Custom Plugins](../development-guide/LoadablePlugins.md#using-custom-plugins).
@@ -79,7 +79,7 @@ For more information, see [Custom Plugins](../development-guide/LoadablePlugins.
## Logging
The AWS Python Driver uses the standard [Python logging module](https://docs.python.org/3/library/logging.html) to log information. To configure logging for the AWS Python Driver, refer to [this section of the Python logging docs](https://docs.python.org/3/howto/logging.html#configuring-logging). Please note the following:
-- As mentioned in a warning in [this section](https://docs.python.org/3/howto/logging.html#configuring-logging), existing loggers will be disabled by default when fileConfig() or dictConfig() is called. We recommend that you pass `disable_existing_loggers=False` when calling either of these functions.
+- As mentioned in a warning in [this section](https://docs.python.org/3/howto/logging.html#configuring-logging), existing loggers will be disabled by default when `fileConfig()` or `dictConfig()` is called. We recommend that you pass `disable_existing_loggers=False` when calling either of these functions.
- The AWS Python Driver uses module-level loggers, as recommended in the Python docs. You can configure a specific module's logger by referring to its module path. Here is an example `logging.conf` file that configures logging for the failover plugin:
```
[loggers]
diff --git a/docs/using-the-python-driver/using-plugins/UsingTheAwsSecretsManagerPlugin.md b/docs/using-the-python-driver/using-plugins/UsingTheAwsSecretsManagerPlugin.md
index c38c424a..1a9f0169 100644
--- a/docs/using-the-python-driver/using-plugins/UsingTheAwsSecretsManagerPlugin.md
+++ b/docs/using-the-python-driver/using-plugins/UsingTheAwsSecretsManagerPlugin.md
@@ -26,7 +26,7 @@ The following properties are required for the AWS Secrets Manager Connection Plu
*NOTE* A Secret ARN has the following format: `arn:aws:secretsmanager:::secret:Secre78tName-6RandomCharacters`
## Secret Data
-The plugin assumes that the secret contains the following properties `username` and `password`
+The plugin assumes that the secret contains the following properties: `username` and `password`.
### Example
diff --git a/docs/using-the-python-driver/using-plugins/UsingTheDeveloperPlugin.md b/docs/using-the-python-driver/using-plugins/UsingTheDeveloperPlugin.md
index 3eb2ffa2..809a3db3 100644
--- a/docs/using-the-python-driver/using-plugins/UsingTheDeveloperPlugin.md
+++ b/docs/using-the-python-driver/using-plugins/UsingTheDeveloperPlugin.md
@@ -1,6 +1,7 @@
-## Developer Plugin
+# Developer Plugin
-> [!WARNING] The plugin is NOT intended to be used in production environments. It's designed for the purpose of testing.
+> [!WARNING]\
+> The plugin is NOT intended to be used in production environments. It's designed for the purpose of testing.
The Developer Plugin allows developers to simulate failures by providing a mechanism to raise exceptions when connection operations occur. By simulating these failures, developers can verify that their application handles these scenarios correctly.
@@ -8,7 +9,7 @@ Since some exceptions raised by the drivers rarely happen, testing for those mig
The `dev` plugin code should be added to the connection plugins parameter in order to be able to intercept Python calls and raise a test exception when conditions are met.
-### Simulate an exception while opening a new connection
+## Simulate an exception while opening a new connection
The plugin introduces a new class `ExceptionSimulatorManager` that will handle how a given exception will be passed to the connection to be tested.
@@ -32,7 +33,7 @@ AwsWrapperConnection.connect(psycopg.Connection.connect, **params) # this throws
AwsWrapperConnection.connect(psycopg.Connection.connect, **params) # goes as usual with no exception
```
-### Simulate an exception with already opened connection
+## Simulate an exception with already opened connection
It is possible to also simulate an exception thrown in a connection after the connection has been opened.
@@ -53,4 +54,4 @@ conn.cursor() # this throws the exception
conn.cursor() # goes as usual with no exception
```
-It's possible to use callback functions to check Python call parameters and decide whether to return an exception or not. Check `ExceptionSimulatorManager.set_connect_callback` and `ExceptionSimulatorManager.set_method_callback` for more details.
\ No newline at end of file
+It's possible to use callback functions to check Python call parameters and decide whether to return an exception or not. Check `ExceptionSimulatorManager.set_connect_callback` and `ExceptionSimulatorManager.set_method_callback` for more details.
diff --git a/docs/using-the-python-driver/using-plugins/UsingTheFastestResponseStrategyPlugin.md b/docs/using-the-python-driver/using-plugins/UsingTheFastestResponseStrategyPlugin.md
index fe27526a..6fedf59a 100644
--- a/docs/using-the-python-driver/using-plugins/UsingTheFastestResponseStrategyPlugin.md
+++ b/docs/using-the-python-driver/using-plugins/UsingTheFastestResponseStrategyPlugin.md
@@ -26,10 +26,10 @@ conn = AwsWrapperConnection.connect(psycopg.Connection.connect, **params)
```
## Configuration Parameters
-| Parameter | Value | Required | Description | Default Value |
-|------------------------------------|:---------:|:--------:|:--------------------------------------------------------------------------------------------------------|-------------------|
-| `reader_response_strategy` | `String` | Yes | Setting to `fastest_reponse` sets the reader response strategy to choose the fastest host using the Fastest Response Strategy Plugin | `random` |
-| `response_measurement_interval_ms` | `Integer` | No | Interval in milliseconds between measuring response time to a database host | `30_000` |
+| Parameter | Value | Required | Description | Default Value |
+|------------------------------------|:---------:|:--------:|:-------------------------------------------------------------------------------------------------------------------------------------|---------------|
+| `reader_response_strategy` | `String` | Yes | Setting to `fastest_reponse` sets the reader response strategy to choose the fastest host using the Fastest Response Strategy Plugin | `random` |
+| `response_measurement_interval_ms` | `Integer` | No | Interval in milliseconds between measuring response time to a database host | `30_000` |
## Host Response Time Monitor
@@ -60,4 +60,4 @@ conn = AwsWrapperConnection.connect(
### Sample Code
[Postgres fastest response strategy sample code](../../examples/PGFastestResponseStrategy.py)
-[MySQL fastest response strategy sample code](../../examples/MySQLFastestResponseStrategy.py)
\ No newline at end of file
+[MySQL fastest response strategy sample code](../../examples/MySQLFastestResponseStrategy.py)
diff --git a/docs/using-the-python-driver/using-plugins/UsingTheReadWriteSplittingPlugin.md b/docs/using-the-python-driver/using-plugins/UsingTheReadWriteSplittingPlugin.md
index 52b01cbe..d47c59bc 100644
--- a/docs/using-the-python-driver/using-plugins/UsingTheReadWriteSplittingPlugin.md
+++ b/docs/using-the-python-driver/using-plugins/UsingTheReadWriteSplittingPlugin.md
@@ -42,27 +42,27 @@ When `read_only` is first set on an `AwsWrapperConnection` object, the Read/Writ
The AWS Advanced Python Driver currently uses [SqlAlchemy](https://docs.sqlalchemy.org/en/20/core/pooling.html) to create and maintain its internal connection pools. The [Postgres](../../examples/PGReadWriteSplitting.py) or [MySQL](../../examples/MySQLReadWriteSplitting.py) sample code provides a useful example of how to enable this feature. The steps are as follows:
-1. Create an instance of `SqlAlchemyPooledConnectionProvider`, passing in any optional arguments if desired:
+1. Create an instance of `SqlAlchemyPooledConnectionProvider`, passing in any optional arguments if desired:
- The first optional argument takes in a `Callable` that can be used to return custom parameter settings for the connection pool. See [here](https://docs.sqlalchemy.org/en/20/core/pooling.html#sqlalchemy.pool.QueuePool) for a list of available parameters. Note that you should not set the `creator` parameter - this parameter will be set automatically by the AWS Advanced Python Driver. This is done to follow desired behavior and ensure that the Read/Write Splitting Plugin can successfully establish connections to new instances.
- The second optional argument takes in a `Callable` that can be used to define custom key generation for the internal connection pools. Key generation is used to define when new connection pools are created; a new pool will be created each time a connection is requested with a unique key. By default, a new pool will be created for each unique instance-user combination. If you would like to define a different key system, you should pass in a `Callable` defining this logic. The `Callable` should take in a `HostInfo` and `Dict` specifying the connection properties and return a string representing the desired connection pool key. A simple example is shown below.
-> [!WARNING]\
-> If you do not include the username in the connection pool key, connection pools may be shared between different users. As a result, an initial connection established with a privileged user may be returned to a connection request with a lower-privilege user without re-verifying credentials. This behavior is inherent to the nature of connection pools and not a bug with the driver. `ConnectionProviderManager.release_resources` can be called to close all pools and remove all cached pool connections.
-
- ```python
- def get_pool_key(host_info: HostInfo, props: Dict[str, Any]):
- # Include the URL, user, and database in the connection pool key so that a new
- # connection pool will be opened for each different instance-user-database combination.
- url = host_info.url
- user = props["username"];
- db = props["dbname"]
- return f"{url}{user}{db}"
+ > [!WARNING]\
+ > If you do not include the username in the connection pool key, connection pools may be shared between different users. As a result, an initial connection established with a privileged user may be returned to a connection request with a lower-privilege user without re-verifying credentials. This behavior is inherent to the nature of connection pools and not a bug with the driver. `ConnectionProviderManager.release_resources` can be called to close all pools and remove all cached pool connections.
- provider = SqlAlchemyPooledConnectionProvider(
- lambda host_info, props: {"pool_size": 5},
- get_pool_key)
- ConnectionProviderManager.set_connection_provider(provider)
- ```
+ ```python
+ def get_pool_key(host_info: HostInfo, props: Dict[str, Any]):
+ # Include the URL, user, and database in the connection pool key so that a new
+ # connection pool will be opened for each different instance-user-database combination.
+ url = host_info.url
+ user = props["username"];
+ db = props["dbname"]
+ return f"{url}{user}{db}"
+
+ provider = SqlAlchemyPooledConnectionProvider(
+ lambda host_info, props: {"pool_size": 5},
+ get_pool_key)
+ ConnectionProviderManager.set_connection_provider(provider)
+ ```
2. Call `ConnectionProviderManager.set_connection_provider`, passing in the `SqlAlchemyPooledConnectionProvider` you created in step 1.
@@ -106,7 +106,7 @@ conn = AwsWrapperConnection.connect(psycopg.Connection.connect, **params)
| `round_robin` | The round robin strategy will select a reader instance by taking turns with all available database instances in a cycle. A slight addition to the round robin strategy is the weighted round robin strategy, where more connections will be passed to reader instances based on user specified connection properties. | See the rows `round_robin_host_weight_pairs` and `round_robin_default_weight` for configuration parameters |
| `round_robin_host_weight_pairs` | This parameter value must be a `string` type comma separated list of database host-weight pairs in the format `:`. The host represents the database instance name, and the weight represents how many connections should be directed to the host in one cycle through all available hosts. For example, the value `instance-1:1,instance-2:4` means that for every connection to `instance-1`, there will be four connections to `instance-2`.
**Note:** The `` value in the string must be an integer greater than or equal to 1. | `""` (empty string) |
| `round_robin_default_weight` | This parameter value must be an integer value. This parameter represents the default weight for any hosts that have not been configured with the `round_robin_host_weight_pairs` parameter. For example, if a connection were already established and host weights were set with `round_robin_host_weight_pairs` but a new reader node was added to the database, the new reader node would use the default weight.
**Note:** This value must be an integer greater than or equal to 1. | 1 |
-| `fastest_response` | The fastest_response strategy will select reader instances based on which database instance has the fastest response time. Note that this strategy requires that the `fastest_response_strategy` and `read_write_splitting` plugins are both enabled. See [`Fastest Response Strategy Plugin`](./UsingTheFastestResponseStrategyPlugin.md) | N/A |
+| `fastest_response` | The fastest_response strategy will select reader instances based on which database instance has the fastest response time. Note that this strategy requires that the `fastest_response_strategy` and `read_write_splitting` plugins are both enabled. See [`Fastest Response Strategy Plugin`](./UsingTheFastestResponseStrategyPlugin.md) | N/A |
### Limitations
diff --git a/tests/unit/test_verify_links.py b/tests/unit/test_verify_links.py
index 4f6e5aaf..97dcba41 100644
--- a/tests/unit/test_verify_links.py
+++ b/tests/unit/test_verify_links.py
@@ -59,7 +59,6 @@ def test_verify_relative_links(docs_dict, docs_list):
list = findall(link_re, f.read())
for link in list:
full_link = docs_dict[doc] + link
-
assert "jdbc" not in full_link
assert path.exists(full_link)