Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Overriding Versions #36

Open
sixlive opened this issue Aug 31, 2017 · 1 comment
Open

Support for Overriding Versions #36

sixlive opened this issue Aug 31, 2017 · 1 comment

Comments

@sixlive
Copy link
Collaborator

sixlive commented Aug 31, 2017

Use Cases

  • Major API Versioning (e.g. api.example.com/v1)
  • Alternative storage for migration versions

Implementation

So I'm thinking an elegant solution for this would be some way of over riding the versions array, similar to ResposeMigrations::setVersion(). This would provide plenty of flexibility to pull the versions in from wherever you please, just using modifying the config as an example.

We would need a way to override the current version as well RequestMigrations::setCurrentVersion('YYYY-MM-DD') so we know what the current version is depending on which subset you use. We should also add it to RequestMigrations::setMigrations($migrations, $currentVersion). (open to some input here)

ExampleMiddleware.php

ResponseMigrations::setMigrations(config('request-migrations.versions.version_2'))`

config/request-migrations.php

...
'versions' => [
    'version_1' => [
        'YYYY-MM-DD' => [
            \App\Http\Migrations\ExampleChangeFieldName::class
        ],
    ],
    'version_2' => [
        'YYYY-MM-DD' => [
          \App\Http\Migrations\ExampleChangeFieldName::class
        ],
    ],
],
...
@sixlive
Copy link
Collaborator Author

sixlive commented Sep 6, 2017

I've got most of this implementation done, will PR soon 🤙🏻!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant