Add a script handler to run the database update classes about installation-bundle

[Toflar]

I don't think that migration should take place automatically every time you update or install bundles. Migration is something that should actively be monitored by the administrator and thus also be executed manually.

[aschempp]

A composer script handler certainly feels wrong. We should use Doctrine migrations anyway, but I'm not sure if that can easily be bundled in a library.

[bytehead]

I vote also against automatic database updates.

[leofeyer]

It seems you all got the ticket wrong. I am not talking about schema updates, which should definitely not be automated. I am talking about the version updates (see the classes I have listed above); and those have been executed automatically in the install tool ever since. 😄

[aschempp]

I'm very well aware of that. Still a composer script feels wrong, also because it would not be executed on deployment in most cases.

[ausi]

I also wouldn’t expect a composer install or update to change my database. It may be better to print a warning on post-update-cmd if the database is out of date.

[fritzmg]

@aschempp why not, aren't you typically executing composer install after deployment?

[ausi]

@fritzmg depends on the deployment. You can also package your application with all vendor files and push it to the server(s).

[fritzmg]

True, but then you need to update the database some other way anyway. e.g. By executing the install tool (I am assuming that functionality will still be present?)

[aschempp]

@fritzmg currently I am, but @leofeyer recommended post-update-cmd which does not run on install. But your last comment says it all: there must be other ways to run that anyway.

[leofeyer]

there must be other ways to run that anyway

Yes, app/console contao:run-version-updates.

[aschempp]

Yeah, not sure about that…

[fritzmg]

If that's the only way, then deployments without accessing the console will not be possible anymore. At least not without deploying the complete (updated) database as well.

[leofeyer]

@aschempp So how do you run the version updates without opening the install tool after every deploy?

[discordier]

I would keep the current behaviour of manually starting the migration via both ways.

• accessing the install tool
• executing app/console contao:run-version-updates

Performing it automatically in post update feels wrong to me.

[aschempp]

Can we find out how other Symfony apps run their update tasks?

[discordier]

By running bin/console doctrine:schema:update ...
or when having orm and migrations bin/console app/console doctrine:migrations:migrate ...
We are, once again, in a special position as we do not define final entities in our application but are merely combining them "on the fly" due to our extension support. Therefore the approach of other projects does not really relate here.

[aschempp]

That would only update the schema, but not the database content. I'm pretty sure there are migrations for existing data in any of the big Symfony projects (http://symfony.com/en/projects).

[discordier]

@aschempp Sorry but your previous statement is not true, it will migrate what you tell it to migrate, that is what the preUp, postUp, 'preDown' postDown functions are for.

Pseudo code translation of src/Database/Version330Update.php

namespace Contao\CoreBundleBundle\Migrations;

use Doctrine\DBAL\Migrations\AbstractMigration;
use Doctrine\DBAL\Schema\Schema;

/**
 * Bump contao database to 3.3.0
 */
class Version330Update extends AbstractMigration

    /**
     * @param Schema $schema
     */
    public function up(Schema $schema)
    {
        // this up() migration is auto-generated, please modify it to your needs
        $this->abortIf(
            $this->connection->getDatabasePlatform()->getName() != 'mysql',
            'Migration can only be executed safely on \'mysql\'.'
        );

        $this->abortIf(
            !$this->connection->getSchemaManager()->tablesExist('tl_layout'),
            'Table tl_layout not present.'
        );
        $columns = $schemaManager->listTableColumns('tl_layout');
        $this->abortIf(isset($columns['viewport']), 'column viewport already present.');
    }

    /**
     * @param Schema $schema
     */
    public function postUp(Schema $schema) {
        $statement = $this->connection->query("SELECT id, framework FROM tl_layout WHERE framework!=''");
        while (false !== ($layout = $statement->fetch(\PDO::FETCH_OBJ))) {
            $framework = '';
            $tmp = \StringUtil::deserialize($layout->framework);
            if (!empty($tmp) && is_array($tmp)) {
                if (false !== ($key = array_search('layout.css', $tmp))) {
                    array_insert($tmp, $key + 1, 'responsive.css');
                }
                $framework = serialize(array_values(array_unique($tmp)));
            }
            $stmt = $this->connection->prepare('UPDATE tl_layout SET framework=:framework WHERE id=:id');
            $stmt->execute([':framework' => $framework, ':id' => $layout->id]);
        }
        // Add the "viewport" field
        $this->connection->query("ALTER TABLE `tl_layout` ADD `viewport` varchar(255) NOT NULL default ''");
    }

// TODO: implement down() and preDown() for going a version back.
?>

[aschempp]

Yeah that is possible, I'm just not sure if it's supposed to be for that. There's also Doctrine Fixtures thought that might be the right thing for website templates.

[discordier]

For templates (in other words: dummy data) you are right, fixtures are the way to go.
However, the migrations are exactly for upgrading (and downgrading) a database in terms of versioning.