Add IContentDefinitionManager to DataMigration

[hishamco]

As we all know almost if not all requires IContentDefinitionManager beside ISchemaBuilder it would be nice to introduce ContentDefinitionManager as property in DataMigration

[Skrypt]

As in you want to be able to add Content Definitions migrations?

[Skrypt]

Basically, what you say is that the DataMigrations class should include the ContentDefinitionManager as a property instead of requiring us to inject it in its constructor every time we need to define a Migration. That part makes sense, though like you said there are use cases where the ContentDefinition is not required.

[hishamco]

Migration in general should interact with data as all knows, but in OC it could deals with content management tables. If you look in many modules almost if not all inject IContentDefinitionManager which is essential, for that instead of injecting the service ourselves let OC do it in our behalf by adding it as property in DataMigration

[Skrypt]

I'm not for or against the idea. But generally, I prefer adding the services I'm required to use in the constructors per need. Now, what you want is to remove these IContentDefinitionManager injections everywhere to make the code lighter. But, will it really will make any difference in the end? You still need to know beforehand that the IContentDefinitionManager is there on the DataMigration as a property else you will try to inject it every time.

[hishamco]

It should make difference to the developer to have the frequently asked services built-in, of sure you need know such properties in advance such as SchemaBuilder. It will be more obvious if we redesign how the data migration should be instead of using Create() and bunch of Update() methods

public override void Up(MigrationBuilder builder)
{
}

where MigrationBuilder is accessor for ISchemaBuilder and IContentDefinitionManager. It's a though that I'm thinking of for make migration easier and extensible. Probably I can share a prototype for such thing in OCC

For now I will leave this to the community to decide either inject every required service or expose the common once by the framework

[Skrypt]

Well, I think better documentation would be a good start. Because there is almost nothing about YesSQL migrations. How to create a table with a foreign key for example? And how to use it inside your code afterward? How to create a ReduceIndexTable, MapIndexTable ... These would be more valuable for everyone.