Running `phpunit` second time fails a tests

[SOHELAHMED7]

If I run ./vendor/bin/phpunit first time after fresh docker-start, all tests passes successfully.

If I run same command second time, all tests passes successfully except one tests\unit\MultiDbSecondaryMigrationTest::testMysql

It is the same issue as in https://github.com/cebe/yii2-openapi/issues/137

I found that this is caused by:

Few tests (e.g. XDbTypeTest) applies (runUpMigrations()) and revert (runDownMigrations()) migrations

        $this->runUpMigrations('mysql', 4);      <------ this
        Yii::$app->db->schema->refresh();
        $this->runFaker();
        $this->runDownMigrations('mysql', 4); <------ this

Stub: https://github.com/SOHELAHMED7/yii2-openapi/pull/20/commits/cef2b0fab3f87cfc8013e02b289b32f73b683aa1

This changes the order of the foreign key stored in MySQL internal DBs.

If I don't applies and revert migrations, this test passes

---

• [x] also fix failing test https://github.com/cebe/yii2-openapi/actions/runs/4495372969/jobs/7908924109
• [x] hint for above: "could be related to ordering of files when reading a file list. If that is the case, sorting alphabetically after reading the list and before doing sort by dependency could help."

[SOHELAHMED7]

@cebe

I found the problem that is causing this issue and described in issue description.

Any hint for the solution?

[cebe]

Maybe before test we should set up a clean DB, drop DB and create DB?

[SOHELAHMED7]

I have also tried that https://github.com/SOHELAHMED7/yii2-openapi/pull/20/files#diff-6dad702ded74e718a0668638486189fbc7a5a8622717cd3245445b6cc939af63R83

but got no solution.

I also tried migrate/redo & mirgate/fresh but still got no solution

[SOHELAHMED7]

Tried dropping and creating the DB, but it had no effect. because FK are stored in MySQL internal DB information_schema.REFERENTIAL_CONSTRAINTS and similar. Order they are stored are changed when other FK are created and deleted in running migrations in other tests

SELECT
    `kcu`.`CONSTRAINT_NAME` AS `constraint_name`,
    `kcu`.`COLUMN_NAME` AS `column_name`,
    `kcu`.`REFERENCED_TABLE_NAME` AS `referenced_table_name`,
    `kcu`.`REFERENCED_COLUMN_NAME` AS `referenced_column_name`
FROM `information_schema`.`REFERENTIAL_CONSTRAINTS` AS `rc`
JOIN `information_schema`.`KEY_COLUMN_USAGE` AS `kcu` ON
    (
        `kcu`.`CONSTRAINT_CATALOG` = `rc`.`CONSTRAINT_CATALOG` OR
        (`kcu`.`CONSTRAINT_CATALOG` IS NULL AND `rc`.`CONSTRAINT_CATALOG` IS NULL)
    ) AND
    `kcu`.`CONSTRAINT_SCHEMA` = `rc`.`CONSTRAINT_SCHEMA` AND
    `kcu`.`CONSTRAINT_NAME` = `rc`.`CONSTRAINT_NAME`
WHERE `rc`.`CONSTRAINT_SCHEMA` = database() AND `kcu`.`TABLE_SCHEMA` = database()
AND `rc`.`TABLE_NAME` = 'itt_v2_comments' AND `kcu`.`TABLE_NAME` = 'itt_v2_comments'

constraint_name	column_name	referenced_table_name	referenced_column_name
fk_v2_comments_post_id_v2_posts_uid	post_id	itt_v2_posts	uid
fk_v2_comments_author_id_v2_users_id	author_id	itt_v2_users	id

Found that 2 tests are causing this issue. RelationsInFakerTest.php and XOnXFkConstraintTest.php, if they are removed this issue is fixed

Attempted to fix this issue but got no solution.

Applied work-around and fixed this issue. Changed DB from MySQL to PgSQL

[cebe]

if order in db changes we can sort the keys after reading them from db schema class.

[SOHELAHMED7]

Yes we can sort the keys. I thought of applying it here

But I haven't tried thinking that

• it will be not be the perfect solution
• even if it passes this tests, it may fail some other tests and or might change some other behaviour in the lib
• we don't have concrete information when we should apply such manual sort and when to not

Still if you want me to try that out I am happy to do