Automatically provide Messenger Doctrine schema to "diff"

[weaverryan]

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
Deprecations?	no
Tickets	Alternative to #36629
License	MIT
Doc PR	TODO - WILL be needed

This follows this conversation: #36629 (comment) - it automatically adds SQL to Doctrine's migration/diff system when features are added the require a database table:

The new feature works for:

A) Messenger Doctrine transport

FULL support
Works perfectly: configure a doctrine transport and run make:migration

Note: There is no current way to disable this. So if you have auto_setup ON and you
run make:migration before trying Messenger, it will generate the table SQL. Adding a
flag to disable it might be very complicated, because we need to know (in DoctrineBundle, at compile time) whether or not this feature is enabled/disabled so that we can decide not to add messenger_messages to the schema_filter.

B) PdoAdapter from Cache

FULL support
Works perfectly: configure a doctrine transport and run make:migration

C) PdoStore from Lock

PARTIAL support
I added PdoStore::configureSchema() but did NOT add a listener. While PdoStore does accept a DBAL Connection, I don't think it's possible via the framework.lock config to create a PdoStore that is passed a Connection. In other words: if we added a listener that called PdoStore::configureSchema if the user configured a pdo lock, that service will never have a Connection object... so it's kind of worthless.

NEED: A proper way to inject a DBAL Connection into PdoStore via framework.lock config.

D) PdoSessionHandler

NO support

This class doesn't accept a DBAL Connection object. And so, we can't reliably create a listener to add the schema because (if there are multiple connections) we wouldn't know which Connection to use.

We could compare (===) the PDO instance inside PdoSessionHandler to the wrapped PDO connection in Doctrine. That would only work if the user has configured their PdoSessionHandler to re-use the Doctrine PDO connection.

The PdoSessionHandler already has a createTable() method on it to help with manual migration. But... it's not easy to call from a migration because you would need to fetch the PdoSessionHandler service from the container. Adding something

NEED: Either:

A) A way for PdoSessionHandler to use a DBAL Connection
or
B) We try to hack this feature by comparing the PDO instances in the event subscriber
or
C) We add an easier way to access the createTable() method from inside a migration.

TODOs

• Determine service injection XML needed for getting all PdoAdapter pools
• Finish DoctrineBundle PR: Add support for new MessengerTransportDoctrineSchemaSubscriber doctrine/DoctrineBundle#1163

[weaverryan]

Basically, if this makes sense, I will:

A) Complete this for Messenger with tests
B) Propose the DoctrineBundle PR
C) (At least) make a list of the other areas in the system that need this type of thing

[Koc]

Should we deprecate schema filters from doctrine/DoctrineBundle#1037 PR if current will be merged?

[weaverryan]

Should we deprecate schema filters from doctrine/DoctrineBundle#1037 PR if current will be merged?

@Koc At least for Messenger & Cache, definitely. In fact, I'd argue we should we remove them: this feature will replace them

For Lock & PdoSessionStorage, they will probably need to stay, as this PR doesn't fix those situations - at least not all the way.

[weaverryan]

This is ready - test failures look unrelated.

I'm super happy with the Messenger & Cache integration and very dissatisfied with the Lock & Session integration. My instinct is that we need to save a proper Lock & Session solution for later.

Cheers!

[nicolas-grekas]

super nice!

[fabpot]

Thank you @weaverryan.

[bendavies]

@weaverryan what does a migration look like if the postgres messenger trigger is updated, after being migrated for the first time?