migrations

migrations copied to clipboard

Right now AbstractMigration has some protected methods and methods that we might not to want users to be able to depend on. Lets create an interface to define which methods the user can actually depend on BC.

/cc @Majkl578

I still think this should happen at some point, why did you close it?

We can reopen if you want to put down more concrete ideas on what needs to happen. I'm not sure the BC break is worth it.

I would leave it open, unmilestoned, to be discussed and done later for 3.0 for example.

Here's my rough and not BC idea (originally shared privately):

splitting it completely: transactional -> marker interface, reversible migration as opt-in interface etc. addSql should go out completely (passed as parameter), write() should be converted to Output/Writer passed though parameter, *if moved out too (helper) primarily to make migrations stateless (free constructor) and smaller units

@enumag Do you have any specific ideas?

@Majkl578 Assuming that migrations would be stateless, we need to figure out the new API. Basically the only things the Migration needs to receive are Schema and Version (everything else is pulled from Version in AbstractMigration::__construct()). Instead of Version it would be better to pass an object with a specialized API for what the migration is supposed to do - the methods would likely be close to what AbstractMigration currently has. Possibly some others based on what migrations might need to do with Connection, SchemaManager and Platform (current protected properties of AbstractMigration). I'm not quite sure what these are used for. I'm always trying to keep my migrations as simple as possible so I'm not using them.