I'm getting an interesting error in my logs.

[2017-06-23 17:19:00] local.ERROR: exception 'Symfony\Component\Debug\Exception\FatalErrorException' with message 'parse error, expecting `';'' or `'{''' in /PATHTOAPPLICATION/vendor/spatie/laravel-migrate-fresh/src/Commands/MigrateFresh.php:59
Stack trace:
#0 {main}  

The line in question: https://github.com/spatie/laravel-migrate-fresh/blob/master/src/Commands/MigrateFresh.php#L59

The things that make this error interesting:

1. It shows up only in the laravel.log file
2. The command works fine when ran
3. It seems to show up in the log every time the scheduler is ran from crontab (every minute)
4. I setup a new laravel installation and pulled in only this package and it does show the error

It seems to have something to do with the return type. If I remove the return type it works fine.

Although for the majority of simple, in terms of DB schema, projects just a table dropper will suffice, but technically speaking there are other very important objects in the database that can be migrated and should be taken care of:

• sequences - the ones that weren't created as part of SERIAL data type and therefore won't be affected by CASCADE
• functions
• custom data types and domains

And there is also a situation when one may use multiple schemas in the database for very good and practical reasons i.e. separating staging/processing and factual schemas.

Thanks for this project, it's very helpful.

I unfortunately have a project that contains an un-namespaced class called "Schema" that I'm having to integrate into a Laravel app. I can't alter that class, so in my own migrations I've had to fully qualify the Schema facade. I know this isn't your problem at all, but it would be helpful to me (and perhaps future others in my situation) if you could fully qualify the use Schema in Spatie\MigrateFresh\TableDroppers\Mysql, like so:

<?php

namespace Spatie\MigrateFresh\TableDroppers;

use DB;
use stdClass;
use Illuminate\Support\Facades\Schema;

class Mysql implements TableDropper

If not, no worries... Just close this issue and I'll work with a personal fork.

Hello,
do you think, that adding support for LaravelDoctrine Migrations (http://www.laraveldoctrine.org/docs/1.3/migrations) makes sense for this base package? I see lot of people lately, who are starting to use Doctrine on Laravel (I also understand why) and this might be useful for them.

Technically, it simply means not calling migrate, but doctrine:migrations:migrate. But there will be need for configuration. I'm thinking standard migrate-fresh.php published into config_path(), where you would specify usage of Laravel migrations or Doctrine migrations.
Feature detection is not possible, since people can use Doctrine with Laravel migrations and vice versa.

I can make PR for that, if you are interested to have it in your package.

Thanks, Jakub

Command tries to drop views as tables and it stops the execution of the code.

hi, when using the comand i get the error:

ERROR:  cannot drop table  
   spatial_ref_sys because extension postgis requires it                       
  HINT:  You can drop extension postgis instead.

In laravel it was solved excluding the table for the drop command, as show in:
https://github.com/laravel/framework/pull/21778/files
and
laravel/framework#21778

can you add the patch please?

ty

First of all, thank you for your awesome contributions.

My concern is that running this inside shared Homestead drops tables that belong to other projects.

There should be implementation of some safeguards that let's the developer know what tables are about to be dropped and a possibility to bail out before any destructive actions take place.

You are welcome to check out how I implemented it in our similar command. It's still in development and takes a bit different approach (and hasn't been tested yet).

I'd propose to change the interface to something like

namespace Spatie\MigrateFresh\DbObjectDroppers;

interface DbObjectDropper
{
    public function dropAll();
}

to better reflect the reality - tables are not the only database objects that need to be taken care of.

@freekmurze What is your take on it? I can do the PR and probably help with MySQL and SQLite droppers.

Hello,
I think we can add an option to only clean data and not data + tables.

It would be very useful to be able to specify the --path and --database options for use cases where multiple database connections and migration directories are used.

using this code
https://gist.github.com/reinink/7af438bc98de72d33acf8d6c9843daf1

When creating & loading snapshots via the command snapshot:create and snapshot:load, an error occurs, because the table names get prefixed twice.

testuser@e61ca43e6aa7:/var/www/laravel$ ./artisan snapshot:create                                                   
Creating new snapshot...
Snapshot `2018-12-20_15-26-06` created (size: 9.59 MB)
testuser@e61ca43e6aa7:/var/www/laravel$ ./artisan snapshot:load 2018-12-20_15-26-06

In Connection.php line 664:
                                                                                                                                                               
  SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'homestead.lv_lv_localfinder_categories' (SQL: drop table `lv_lv_localfinder_categories`)  
                                                                                                                                                               

In PDOStatement.php line 143:
                                                                                                              
  SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'homestead.lv_lv_localfinder_categories'  
                                                                                                              

In PDOStatement.php line 141:
                                                                                                              
  SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'homestead.lv_lv_localfinder_categories'  
                                                                                                              

I have tracked it down to Spatie\MigrateFresh\TableDroppers\Mysql::dropAllTables(), apparently Schema::drop() expects the table name without the prefix, but the query SHOW FULL TABLES WHERE Table_Type = 'BASE TABLE' returns the full table name. Probably this has changed in laravel at some point? I am using laravel v5.5.40

My current work around is to use a custom command, which sets the database prefix to an empty string before calling the snapshot:load command:

// in a custom console command handle()
\DB::connection(\DB::getDefaultConnection())->setTablePrefix('');
$this->call('snapshot:load', ['name' => $name]);

Is there any way to use with a Laravel 5.2 installation? Thank you