phinx icon indicating copy to clipboard operation
phinx copied to clipboard
verified publisher icon cakephp

Adapter should not depend on MigrationInterface

Open theluk opened this issue 11 years ago • 6 comments

The AdapterInterface violates the separation as it knows about the MigrationInteface in the migrated method. We are for example using phinx´ adapter structure but have a slightly different MigrationInterface ( no downs ) and different Manager (Module-specific) Currently we need to "hack" the migrated function, even though there does not come any MigrationInterace in... So this "migrated" thing should be in the Manager, not in the Adapter

theluk avatar May 06 '14 11:05 theluk

Sure but the adapters may need to have a custom implementation of the 'migrated' logic. So how else can we achieve that?

robmorgan avatar May 06 '14 13:05 robmorgan

I think it should be in the table class. or something similar. exactly for this the table class is made, isnt it? In the Adapter methods like "createRecord" should exist, not business-logic specific (migration specific) stuff, like migrated.

theluk avatar May 06 '14 13:05 theluk

Anyways there are many things that do not belong to where they are right now. For example a typical manager, that can get you all the migrations and execute them, should not have to do anything with a Output in the CLI. I believe if you start modularize your tools, a MigrationManager should only "list", "execute" or "add" migrations. A migrations should only migrate. An Adapter should only translate commands into its dialect. And then, you got the glue, for example a web app, or a cli app. There your bring all the stuff together. Only the app knows what to put in what. If I am writing a CMS, where you can upload plugins, than your Manager would not be suitable, as it is made only for CLI. But a Manager should work anywhere.

theluk avatar May 06 '14 13:05 theluk

@theluk do you a have a existing codebase of sorts, regardless of the language, that demonstrates the gists of the idea your capturing in your feedback? If so, please share

ghost avatar Oct 06 '14 17:10 ghost

I've had some time recently to review this and I agree it makes sense to move this logic out of the adapters.

My proposal:

  • [ ] Move the migrated method out of the AdapterInterface and into the Environment class
  • [x] Introduce an insert method to the AdapterInterface and each adapter
  • [ ] Introduce a delete method to the AdapterInterface and each adapter

robmorgan avatar Oct 06 '14 19:10 robmorgan

Does anyone want to complete this?

dereuromark avatar Dec 19 '19 19:12 dereuromark