digifactory / laravel-pull-production-data Goto Github PK

It would be great to optionally set 'local so there will be a check if there is still a local backup from last pull-production-data that can be imported. This way you can save much time when you need a fresh large database multiple times in a short period of time.

It would be a nice feature to show the download progress. At the moment you are just waiting for it to finish, but without the knowledge when it will finish.
This can be implemented either directly in the download process, or as an option such as -p | --process.

I think we should create an option to configure some kind of classes that contain code to anonymize or in any other way alter data after pulling the production data.

Maybe we can (re-)seed the database after pulling the production backup so we always have a specific account available?

Maybe we could improve the backup process on the server-side according to some extra option-parameters.

For the function fetchProductionDatabaseBackup:

• --quick

• --compact

• --compress

For most projects we only need storage/app, however there are some occasions where we might need additional paths.

Maybe we can use https://github.com/spatie/email-concealer to ensure we have no real email addresses in the database?

Option to store the downloaded database file. Now it is downloaded, imported and removed. That last option should be optionally.

Maybe we can run php artisan migrate after the production data has been imported. That way all new migrations will run without manually running the migrations.

@m-bosch what do you think?

Hi,

Nice package out there. Would be great if I can specify to exclude certain huge tables. Where in local development I have a smaller subset

If MySQL is not available (-bash: mysql: command not found) that is not visible to the user. To the user it seems everything is worked correctly.

While testing with several project we noticed that importing the sql through Laravel is slow and breaks for large SQL files.

I suggest we make (perhaps optional) the import on command-line level with something like:

exec(mysql ......... < database.sql)