October: Plugin create:migration command

[carlosdubus]

Hi, I'm wondering why you decided to use a version.yaml file instead of using the laravel naming for plugin migrations?
php artisan migrate --path plugins/foo/bar/updates does not seem to work.

Is there a command to create a migration for a plugin?
Something like php artisan create:migration Foo.Bar that would scaffold a new migration inside a foo/bar/updates directory and update the updates/version.yaml file?

If not, I can contribute by writing it.

Thanks!

[dshoreman]

Plugin migrations use a different system to allow for things like refreshing a specific plugin, which wouldn't be possible (at least not easily) with the basic Laravel all-or-nothing approach.

There is already a migration stub but it's the bare minimum and runs as part of php artisan create:model Vendor.Plugin Model.

+1. I for one would welcome some good migration generation in October

[daftspunk]

A migration is generated every time a model is created using the create:model command, currently. Can you provide some examples where the create:migration command would be useful? In other words, write the text that would appear in the documentation for this command, with examples.

Keep in mind there are 2 types of migrations, seeds and schema. So this should probably be accounted for.

[carlosdubus]

Suppose you are working on a plugin, you first did create:model, then you push the site to production. Data is added to the model table. Now you want to add a new column to the model. plugin:refresh will erase the data and we want to keep the data. That's an scenario where create:migration Foo.Bar Model would be handy. It could add a new empty migration file and also updates the version.yaml.

Then I can run october:up, or even better a command like plugin:migrate Foo.Bar that would perform migration on a single plugin.

Does that makes sense?

PD. Maybe migrations is not OctoberCMS responsibility in this case, and I should just handle the db migrations on my own. Let me know your thoughts.

[daftspunk]

Can see some utility in this for sure.

Example seed: https://github.com/rainlab/blog-plugin/blob/master/updates/seed_all_tables.php
Example schema: https://github.com/rainlab/blog-plugin/blob/master/updates/update_timestamp_nullable.php

We just build these classes by hand at the moment. So for a create:migration command, we need to write the documentation first, to get an idea of what it would look like.

[prajwolonta]

Suppose you are working on a plugin, you first did create:model, then you push the site to production. Data is added to the model table. Now you want to add a new column to the model. plugin:refresh will erase the data and we want to keep the data. That's an scenario where create:migration Foo.Bar Model would be handy. It could add a new empty migration file and also updates the version.yaml.

Then I can run october:up, or even better a command like plugin:migrate Foo.Bar that would perform migration on a single plugin.

Does that makes sense?

PD. Maybe migrations is not OctoberCMS responsibility in this case, and I should just handle the db migrations on my own. Let me know your thoughts.

@carlosdubus is this information anywhere in the official documentation of octobercms?

[LukeTowers]

@lowjarp that command doesn't exist in October, but it could be added. See https://github.com/octobercms/library/blob/master/src/Scaffold/Console/CreateCommand.php for an example of an existing stub file.

I would like the API of the command to look something like this create:migration Author.Plugin Model --name=name_of_migration_file. Perhaps we could also add a similar create:seeder. @bennothommo any thoughts on that?

[Samuell1]

@LukeTowers agree with this and it will be cool if there is way to add Pivot model and migration too

[bennothommo]

@LukeTowers that would be a great addition. Perhaps the only thing I would suggest to add for both would be --description for the update description to be inserted into updates.yaml. That way, the only thing that needs to be manually modified would be the migration itself.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see action on it, please respond and we will get the ball rolling.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days.

• If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue. - If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days.
If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.
If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days.
If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.
If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.