Skip a connection to execute set_config if the vendor is not postgresql

[askerka]

No description provided.

[funkybob]

Given this package is explicitly for integration with Postgres, could you please elaborate under which conditions the vendor would not be postgresql?

[askerka]

Given this package is explicitly for integration with Postgres, could you please elaborate under which conditions the vendor would not be postgresql?

Easy. Django supports Multiple databases, and one of them could be not Postgres while the one that is used by the package is Postgres.

But this hook is executed on every established connection even if that is not related to the package.

[funkybob]

Makes sense.

ISTM the better solution, then, would be to find a way to ensure this is only run on the desired database entry. Perhaps an optional setting?

[askerka]

OK, let me try to find another way how we can achieve this

[askerka]

Hi @funkybob

Please, have a look.

The PR is quite heavy right now, but most of it is testing files, they can be removed.

The main changes are settings parsing, and DATABASE_ALIAS setting instead of a Postgres URL. This allows us to reuse the same database connection which is used for the migration which is important.

I separated settings to make it easier to work with, IMHO.

Let me know if you are OK with this approach.

[funkybob]

Why add this complexity of the router?

Surely the migration itself can check schema_editor.connection ?

[askerka]

Without the router, the migration will be applied to the default alias In the case of multiple database support.

So the router is required in case the DB alias is not "default".

[funkybob]

Did you deliberately remove this?

[askerka]

Yes, this is not necessary anymore because we use the alias to the Django database connection instead of a custom URL

[funkybob]

And you believe it's not possible to want to pass any other options to the Broker?

[askerka]

I just assumed the intention based on the code and documentation.
Let me go through the available broker options.

pool=None,
url="",
results=True,
schema=None,
table=None,
middleware=None

1. pool should be a ThreadedConnectionPool instance that is impossible without additional code just pass as a param
2. url we construct from DATABASE_ALIAS
3. schema and table are already hardcoded in the code in the BackgroundJob.Meta.db_table as default broker values (dramatiq and queue respectively) and previously they were hardcoded as BackgroundJob.Meta.db_table and literal in the signal handler. So passing the different values would cause the problem without changing the code of the migration and SQL script
4. middleware parsed from the MIDDLEWARE
5. results is used to configure Results results middleware with PostgresBackend. This can be achieved via MIDDLEWARE or left result=True as it is.

As the result, the only meaningful and available option for the broker is the results variable which can be:

• left as is
• placed in a separate variable
• added as separate middleware

[askerka]

@funkybob Did I address your concerns?

[askerka]

@funkybob
Eventually, we don't need a signal at all, we just need to specify the qualified table name

db_table = '"dramatiq"."queue"'

[askerka]

Hi @funkybob
Do you have time to review the PR?

[askerka]

Hi @funkybob
The review unexpectedly takes a lot of time. Please let me know if you need any help.
I understand if you are not willing to accept it. If this is the case, please, provide a license under what the library is published, and I'll create a separate fork.