Skip to content


Subversion checkout URL

You can clone with
Download ZIP


[Proposal] artisan migrate:refresh --bench=vendor/package // add --bench to command #1267

kwladyka opened this Issue · 15 comments


I am creating a few packages for L4. It is really annoying when i can't refresh tables in easy way. The process of creating new package with DB tables, especially on the beginning make many changes. All the time when i change conception a little, or make some changes in models, i have to manually rollback exatly tables from that packages (i cant rollback all from whole application) and then run migration in package again. It is not necessary work what can be easy automate. It can also easy make me mistake and i can rollback other table from application with data.

I am creating this package as workbench, because i need context to test and improve this packages. Mayby in the future i will decide to move this packages to be separate but it will take a long time. In my opinion it is standard way to create package, first you will work with some context with real application. After some time mayby you can decide to move package from workbench to real package. But from that time you need make changes in DB :)

My propose is add command:
artisan migrate:refresh --bench=vendor/package


Why can't you just migrate refresh all migrations. Just running back the workbench migrations doesn't make sense, and they could be interspersed throughout the app's migrations.


Even if i refresh all migrations by "artisan migrate:refresh" it rollback all tables, and migrate only tables in app/migrations. It not migrate migrations from workbench package but it rollback theme. So anyway it is not a solution.

In that moment exatly i can, but i can imagine in the future i will work on some working project with data (thousand of rows) in tables. I can need this data in tables for my package to tests. If i refresh all tables i will lose that data.

So the question is how easy refresh tables with one command in workbench package when i am doing changes?

For me it makes sense becuase it saves time and protect from mistakes. "artisan migrate:refresh --bench=vendor/package" should be the easiest and logical way for me. But mayby i dont see something. Anyway problem what i describe exist and need solution.


All of your "thousands of rows" should be in seed files so they can easily be re-created. It still does not make sense to roll back only a package or workbenches migrations, as the migrations could be interspersed or even depend on the application's migrations, you see what I mean.

Just make yourself a little helper to do migrate:refresh, then migrate your workbench, then seed your database.


Ofcourse i can write my own command for that, but i guess many people will be at the some point like me. I think it is really something reapated in process of making package with DB tables. I guess it happen in 99,9%.

What you said make sense for working app on server, but for develop should be something what make live easier :)


I totally agree with you, as there is a way to rollback migrations in the application, there should be a way to refresh the packages in workbench as well, otherwise it is a one way command. You can do artisan migrate --bench=vendor/package but not the re-roll of this migration. I would like to do some integration testing with my database seeds too. Writing a helper is a solution of course, but it doesn't seem to be the best solution to me.


i want this feature too


pfried expressed it better than I would have... but well, I would love that feat too.



You don't rearchitecture a tried and tested framework's workflow to suit your thought process. You rearchitecture your thought process to fit into its workflow. As a package developer, I am rolling back and forth with a variety of workbenches all day long, and the migration batches matter. We don't just pop out a batch somewhere in the middle and re-run it without rolling back the top batches first -- this is one of the reasons why we have seeds, because the order matters.

And, when developing packages especially, the order of the bench's migrations you run has to be performed manually depending on how you're nesting dependencies. That's why you can rollback quickly/automatically but have to specify the benches, one at a time, when migrating forward again. Because you lost the batch order in the process of rolling back.

That being said, I do something like Taylor said when it comes to resetting a whole set of benches at once. You can easily adapt this to take care of your batch order.


You're still assuming all of us want to use workbenches as a way to extend the core applications, ie: adding more tables into the main that case, re-seeding all makes sense. But some of us use workbenches as a way to write applications or "apps" inside a larger laravel based content management system. For me, my workbenches are like stand alone apps or plugins into a cms, these plugins never touch the main database so the workbench migrations idea doesn't work here. My workbenches have their own separate database elsewhere on the system with it's own migrations table. All of this works well EXCEPT the ability to rollback only a these work perfectly

./artisan migrate:make create_mybench_users_table --bench="mreschke/mybench"
./artisan migrate --database=mybench --bench="app/dashboard"
./artisan db:seed --class="MybenchSeeder"
up to this point, working perfectly...the mybench database is on a completely different system than the core cms app with it's own migrations database, no problems.

But now I have no way to roll back only the mybench database, because a migrate:reset or migrate:refresh doesn't take the proper --seeder or --class commands correctly. Also the full migrate+seed of ./artisan migrate:refresh --seed does not work properly for benches even if I use --seeder="MybenchSeeder". So close, but not quite there for benches. My only choice is to delete the mybench database manually, then re migrate it.

also with this conversation, making workbench migrations namespaced per workbench would be a huge benefit as we would not have to make our migrations "unique" by adding junk like _mybench_users_table to separate between the main core apps users table. Workbenches are so close to being complete stand alone apps (not "bundles" to your main system) with full independent migrations , but not quite there. I know about but that is just to add a namespace to all migrations, not per workbench. No ability for multiple migrations namespaces and truly independent bench migrations.


+1 for migrate:reset --bench


All this stuff is removed in laravel 5. This is never going to happen.


Can't wait to learn the new way in L5


@mreschke The new way is there is no way. You now have to manually override config in service providers.


@GrahamCampbell is this official now? :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.