Improving migration running & adding config. option for setting database user host

[gabfr]

Hi!

First of all, thanks for such a great package. I made a few changes that I believe that may be useful for somebody out there. They are:

• I changed the way we run the tenant:migrate, because when I specify an array of migration paths, essentially I want them to run accordingly with their migration base names (the date of creation of the migration - we do not want to run into out-of-sequence-migration-running). The only problem is that I had to make a little change into the Laravel´s migrator to accept migration files paths instead of directory paths only (I intend to open a pull request on Laravel´s framework repository too).
• Also, I created a configuration option called tenancy.db.tenant-database-user-host-permission to allow specifying a host when creating a new database user for a new site, enabling the multi-tenant to work with databases servers in another machines

That's it

[luceos]

Migration paths

Okay I need to think the migration thing over and we're going to wait on the reply on the framework first. We don't want to introduce features they already have or will have.

User host permission

• Can you please not combine two features into one PR. Please remove the tenancy.db.tenant-database-user-host-permission code.
• Can you clarify the need to use a different Database host for creating a user and its permissions? We already have the managing connection feature that allows you use any number of secondary system connections.

---

PRs with failing tests will not be merged.

[gabfr]

@luceos the database host on the user permissions is not about where we will connect. It is about from where we connect. When you try to make a mysql connection from another machine on the same network that your mysql server machine is, without creating a user specifying its host or IP address from where its connecting.

You will get a permission denied, until you create a user specifying the IP or hostname from where it will be connecting.

Take a look at this stackoverflow: https://stackoverflow.com/a/16288118

Anyway, I’ll separate it in two PRs. Sorry for the mess.

—
And about the migration things, my PR got accepted in the Laravel Framework repository, so I believe its safe to say that we can merge this modification of how the migrations run.

[luceos]

And about the migration things, my PR got accepted in the Laravel Framework repository, so I believe its safe to say that we can merge this modification of how the migrations run.

Not quite sure, we also have the tenancy:run command which could be used to run tenant migrations now..

@fletch3555 @bkintanar ?

[gabfr]

Yes, you do have the command to run tenancy migrations.

But have you ever tried specifying an array of migration paths on the tenancy.db.tenant-migrations-path configuration, and then running your console command tenancy:migrate?

Sorry for the lack of proper markdown here. I’m typing from my phone

[luceos]

have you ever tried specifying an array of migration paths

No because that's a pretty unusual scenario ;) I'm still waiting for an opinion from the others before I decide on this.

[bkintanar]

I have less experience with using migration paths to comment on this matter.

[gabfr]

@luceos haha, yes, it's because I use a module design pattern in my projects that separates the migrations of the modules. But you're right, it's a very unusual scenario

[luceos]

@fletch3555 ?

[fletch3555]

Updating the connection config's host value seems confusing, but it's local so it'll work. Perhaps just change it to a local variable instead.

Not sure how I feel about the config and env name. Seems overly verbose, but maybe I'm just nitpicking.

Not sure getMigrationPaths() belongs on the connection class. What was the reasoning for that vs something else?

I'm sure I could find more but I'm mobile, so reading the diff is a bit difficult.