[v1.0] Improve schema installation on new installs

[luceos]

We decided to flatten the migrations trying to fix the problem of timeouts happening with the web installer, see #2842.

The drawback of the merged approach is that it relies on the mysql binary. Here are some drawbacks of that method:

• cloud based installations never run the mysql-client on the nodes that run the application, they connect to the database using the php mysql module.
• on shared hosting environments the mysql binary might exist, there however is no reason to assume it does because web applications don't use them; many hosting providers also detach their mysql database servers from the web application servers and cause the binary to be not available.
• depending on a raw export completely removes the power that the eloquent/symfony/dbal layer provides in terms of abstraction. If it doesn't already, future changes to the dump will only further remove our ability to allow different database drivers.

My proposal is the following:

We will start storing migrations based on major.minor version string in the migrations directory, so right now that would create these two directories:

• migrations/v0.1
• migrations/v1.0

There are now two scenarios we need to consider; an upgrade or a fresh install.

Upgrades

The migrator (or some code before that) will check the settings table value for version and compare that against the Application::version constant.

• In case the settings version is within the same minor we will just run the migrations from that directory.
• In case more than one folder needs to be migrated and the user is trying to upgrade using the web page, we will recommend switching over to the terminal migrate command.

Fresh installs

The migrator will pull the Application::version constant and look up the migration directory to execute. However, different than the upgrade command it will first run the create table migrations. There are two options of how to implement this (that come to mind):

• migrations/fresh that contains these files
• or inside each version migrations/v1.0/create_<some>_table.php and we filter these out for the upgrade

The drawback I see in the second approach is that we will have unused files. The drawback of the first approach is that you must update the files in fresh whenever you tag a new minor.

[luceos]

I just tried installing Flarum on the host for https://discuss.flarum.org/d/27422-installing-version-100-constant-problems.

I ran into a block because proc_close was disabled for security reasons, which makes a ton of sense. Any php script that runs other processes inside its runtime are a reason for scrutiny and I can imagine on shared hosts they are blocked asap.

So this is another reason to try to go back to using migrations and not a schema dump.

[luceos]

Fixed in 8af5215