Add a schema_provider option that enables the diff command for DBAL

[veewee]

Q	A
Type	feature
BC Break	no
Fixed issues	#1047

Summary

This change makes it possible to configure a schema_provider that enables the diff command for doctrine DBAL as well.

Currently the PR allows you to do:

$dependencyFactory = DependencyFactory::fromConnection(
    new ConfigurationArray([...]),
    new ExistingConnection($connection)
);
$dependencyFactory->setService(SchemaProvider::class, new MySchemaProvider());
MigrationsConsoleRunner::addCommands($application, $dependencyFactory);

In which, MySchemaProvider is a Doctrine\Migrations\Provider\SchemaProvider.

[SenseException]

The code looks good for me so far. For the feature itself @doctrine/team-migrations should take a look first.

[goetas]

Hello. Thanks for working on this.

IMO a schema provider should not be a configuration option but something passed to the dependency container.

Having a callback as configuration value makes configuration non cache-able and impossible to express in XML, JSON or YAML.

What about marking as public getSchemaProvider in the dep-factory and make the needed adjustments to make it work?
I'm also in favor of deprecating/marking-private the getEntityManager, since that method should not be used anywhere outside of the dependency factory.

[goetas]

Actually looking better, things are "almost" working.

$di->setService(SchemaProvider::class, $someSchemaProvider);

will already do the job.
the only thing that needs to be done is to expose the diff command even if the entity manager is not available

[veewee]

@goetas :

If you don't add it through configuration - it has this double way of configuring the tool. It needs proper documentation then.

Shall I give the configuration of the dependency directly another try in this PR or do you want to discuss it first?

[goetas]

If you don't add it through configuration - it has this double way of configuring the tool. It needs proper documentation then.

Indeed it should be documented, I've added in the past how to provide custom entity managers but did not think on the possibility of providing only the schema provider (and I think it is a really good idea for doing so).

I want to distinguish things that are configurations and things that are dependencies. Anything that can not be expressed in all the configuration formats (yaml, xml, json and php) can not go in the configurations pool.
that is the reason why you can not provide a connection via configuration (creating a connection might need access to php dependencies that can not be expressed in the configuration itself).
Later framework integrations (that are able to manage dependencies) can provide a custom dependencies in the form that each frameworks uses to express them (symfony uses its own dependency injection configured with xml or yaml,but laravel or laminas use just plain php)

[goetas]

In 2.x, the configuration object was huge.... mainly because was managing both dependencies and configurations

[veewee]

Ok, thanks for the side information! Will give it a try soon :)

[veewee]

@goetas : I removed the configuration part. Where do you want me to document how to configure a custom schema provider?

( FYI : I've kept the entity manager public, since it would be a BC break. If you want to make it private, you can do it in another PR, so that this new feature can be released in a minor? )

[veewee]

Is there anything I can do in order to get this merged? Thanks!

[goetas]

@veewee i'm sorry for the delay, I got some time back to look into this. Could you please rebase it?
It looks good to me, and i hope that this PR makes its way already in 3.1

[veewee]

@goetas : rebased ;)

[goetas]

I've changed the base branch for this to 3.1.x since it adds a new feature.

Can @SenseException or @greg0ire review this please?

[goetas]

Thanks for your work