When Migrations Fail

Hey Fernando!

Haha, you were more lucky than we ;)

Cheers!

Yeah but, WHY is it not failing. I even tried to give "nullable=false" in the PHPDoc. Still just doing it's migrations. Shouldn't it be halted, unless a consistent database state is given? Like all dates having an actual value?

Also: Why risk running "migrate" on production, if I have to run "DROP TABLE;" if sth. happens? Why not use "--dry-run"?

Hey Neulaender,

I think it just depends on your *SQL DB server and its version.

> Why not use "--dry-run"?

Well, probably because --dry-run does not actually execute queries? It's helpful to see if you have any syntax or logic error in your migrations, like calling invalid method, or calling service that does not exist if you ever do it in migrations, but it won't show you that the query will fail like in the case we had.

Cheers!

same here. not failing

Hey JP,

No errors - even better, right? ;)

Cheers!

i already run the composer require doctrine/doctrine-migrations-bundle "^3.0". But when trying again the php bin/console make:migration still come up with the [ERROR] Missing package: to use the make:migration command

Have the same error with Symfony 5 and "symfony/orm-pack": "dev-master"

Hey Charlene Eboña

That's interesting. Did you start coding from scratch or did you download the course code from this page? Double check that you have installed symfony/orm-pack in your composer.json file, if you don't, then check if you have these 3 libraries installed

doctrine/orm
doctrine/doctrine-bundle
doctrine/doctrine-migrations-bundle

Coding from scratch. Yes the symfony/orm-pack was already in my composer.json

Hmm, interesting, does it says which package is missing? I'm assuming that you have MakerBundle installed as well. Try running the command passing in the -vvv flag to get more debug information

Hey ahmadmayahi

I like to manage myself the "createdAt" field because it is very easy but for the "updatedAt" field, I usually handle it with gedmo's timestampable extension: https://github.com/Atlantic...

Cheers!

Hey MolloKhan ,

updatedAt is just like createdAt it could be done by the lifecycle as follows:

    /**
     * @ORM\PreUpdate()
     */
    public function setUpdatedAt(): void
    {
        $this->updatedAt = new \DateTime();
    }

Oh yea, for sure but you don't need a lifecycle for setting up the "createdAt" field, you only have to set it at the constructor :)

Hey Stileex,

Doctrine bundle does not do any rollbacks manually. If you have an automated deploy script - you should care about doing those rollbacks on failed migration execution, i.e. literally execute another Symfony command, but usually it's difficult to achieve on practice because you may have a few separate queries in your migration and because some of them might be successful in the beginning but failed in the middle of the migration - you would need to rollback only successful queries in down(), but it's difficult to know programmatically which failed and should be rollback-ed - so usually it's not enough to just call rollback automatically and usually it's done manually by devs in complex migrations.

Hope it helps!

Cheers!

Thanks :)

Hey Robert

I guess you have older version of mysql server, or it's configured to avoid this error. By default mysql server is configured with options NO_ZERO_DATE and NO_ZERO_IN_DATE if you don't have this two mods, then your server will not throws errors about wrong datetime.

Cheers!

Hey Karin,

I'm not sure if it's possible for PhpStorm. I use a separate terminal called iTerm2 on Mac and it supports different colors. For PhpStorm, I think the most you can do is to change PhpStorm theme, but it will affect the color of file s content, so it depends on if you will like it or no. Anyway, I'd suggest you to use a separate console for executing commands, it's better IMO. In case you're interested how to change theme in PhpStorm - here it is: https://www.jetbrains.com/h...

Cheers!

I thought moving from stof to antishov's fork (composer require antishov/doctrine-extensions-bundle) would fix the issue for me. But it didn't do anyting appart fixing an annoying deprecation warning. So I'm still there with my modified entity and my make:migration command that sees no change.

Turns out it was a just a cache issue and that executing 'bin/console cache:clear' after updating the entity was the only thing needed. Who knows why.

Hey Brain,

Oh, it sounds like a cache issue, yeah. Trying to clear the cache at first is always a good idea :) Glad it works for you now and you figured out how to solve it yourself! And thank you for sharing your solution with others!

Cheers!

Hey Avraham,

> VersionXXXXXXXXX.php file contains queries not intended at all

Hm, what do you mean? You don't have indentation in that file? Or you mean the query is written in one line? Because it's ok, "make:migration" command does not expand queries to multilines.

Hm, what version of DB do you use? Because it's important to specify the same version for "server_version" option, see https://symfony.com/doc/cur... for more information. Otherwise, migrations might be generated a bit differently and it might cause generating migration instructions diff continuously on every run. Also, make sure you're on the latest version of maker bundle and doctrine migration bundle, sometimes bugs might happen, so upgrading to the newest version is a good idea to start.

I hope this helps!

Cheers!

Thanks Victor!

Hey Victor,
Thanks!

It is not about indentation - that's ok.

I mean VersionXXXXXXX.php file contains unneeded queries I didn't expect to appear,

some generated queries will try to make changes to my table structure I am not interested in.

There is notNull field patient_id without default value,
it is linked to id of patients table filed by Foreign key constraint.
Generated query adds DEFAULT NULL and after running it deletes notNull definition from patient_allergies patient_id field definition.

The annotation is like that:

/**
* @var Patient
*
* @ORM\ManyToOne(targetEntity="Patient")
* @ORM\JoinColumns({
* @ORM\JoinColumn(name="patient_id", referencedColumnName="id")
* })
*/

private $patient;

I see new query will change
$this->addSql('ALTER TABLE patients_allergies CHANGE patient_id patient_id INT UNSIGNED DEFAULT NULL');

If it sounds not practical question, I will sure just inspect the VersionXXXXXXXX.php before running migration.
Thanks!

Hey Avraham,

Well, then yes, what I said about server_version is totally relevant. Also, it depends if you mix the same table for entity data and unrelated to the entity data. I mean, if you have some fields that are not mapped to your entity and that you work with via doctrine DBAL - Doctrine migration might think that those fields should be removed, so better do not mix data in the same table. About foreign key constraints - yes, doctrine generate the key name using some algorithm, so if you were created those keys manually before - Doctrine will try to remove it and create a new one with a different name.

Anyway, you always have to check the final migration, especially if you're working on a legacy project and not all the columns are mapped to the entity properties.

Cheers!

Ok.. Then I configure the timestamp, reload the fixtures, and then retry the migration and it's work :

`
++ migrating 20190109093240

 -> ALTER TABLE article CHANGE created_at created_at DATETIME NOT NULL, CHANGE updated_at updated_at DATETIME NOT NULL

++ migrated (0.25s)

++ finished in 0.25s
++ 1 migrations executed
++ 1 sql queries

`

Hey ojtouch
It's awesome that you solved this yourself.

BTW this error caused by records in table with `null` values in this fields, that's why configuring timestamps solved it.

Cheers!

Thanks sadikoff :)

Hey Dmitriy,

Uh oh, you certainly should avoid running this command on production :)

First of all, you need to understand why this error happened: whether due to bad migration logic or due to developer error like somehow running the same migration twice. When you understand it - you will see what to do next. But here's some possible outcomes for you:

• You can skip this migration by marking it as executed with: bin/console doctrine:migrations:version YYYYMMDDHHMMSS --add - this will not execute the migration but just add it to the table, so on the next bin/console doctrine:migrations:migrate call this migration will be skipped. But make sure that all the SQL statements in the skipped migration were already applied. If not - you will need to manually execute missing one.
• If that table was created mistakenly and do not hold any data - you can try to remove it manually and re-run the migration again to create it. But it depends on what else operations are supposed to be done that migration, probably just manually removing this table won't be enough.

So, in any case, it's very bad and you should think about it and try to do your best to avoid this problem in the future, but for now you have to do extra work to make things working. As a tip, you can use bin/console doctrine:query:sql <sql> command to execute any SQL command on your production.

Cheers!