[Feature] Add a event before/after reset database (and schema creation)

[lsv]

As im working with postgresql, with the postgis extension - This means that you need to enable postgis as an extension on the database.

This works fine, but in my tests, I ofcourse use ResetDatabase, now this drops the database, and therefor it also "deletes" the extension.

So would it be possible to add an event after database creation, but before schema import?

The only way I can do this is by using migrate, but that tripled the time on my test suite.

[nikophil]

Hi @lsv

I think you can leverage global state here.

I have a similar problem: I need some sql views to be created in order to be used in the tests.

I'm using an invokable service to generate them:

// /config/packages/zenstruck_foundry.php

$containerConfigurator->extension('zenstruck_foundry', [
    'global_state' => [
        ViewsGenerator::class,
    ],
]);

and it gets created before each test (actually, before the very first test of the suite, since I'm using dama)

[lhapaipai]

Thank you @nikophil for your answer and the tip, But I think the @lsv issue and the mine :smile: is that createSchema method will fail if we haven't enabled PostGIS extension. The extension offers a set of functions and types that are used to generate our tables. global_state is a bit too late.

// vendor/zenstruck/foundry/src/Test/ORMDatabaseResetter.php
final class ORMDatabaseResetter extends AbstractSchemaResetter
{
    // ....

    public function resetDatabase(): void
    {
        $this->dropAndResetDatabase();

        // we need to make this sql query here 'CREATE EXTENSION postgis';
        // because our schema contain PostGIS functions
        
        $this->createSchema();
    }

    // ....
}

Dama couldn't help us either because resetDatabase seems to be called in the beforeClassMethod.

[nikophil]

Hi @lhapaipai

indeed, you're right!

Maybe you could enable migrate mode for the database resetter? You can look at this issue: https://github.com/zenstruck/foundry/issues/477

This comes with a performance cost, which makes dama almost mandatory.

(it was exactly the same problem, and I gave exactly the same wrong answer :clown_face: )

[lhapaipai]

Thank you @nikophil , I imagine this comes with performance cost, but at least it solves the problem !!

[nikophil]

If you use dama, the performance cost is really limited, since the migrations are only ran once.

Maybe this whole problem could be solved by introducing some kind of events in the database creation process

WDYT @kbond ?

[lhapaipai]

ok, I think it could be super useful :smile: !!

[kbond]

WDYT @kbond ?

Yeah, I feel like this makes sense. I believe we've hardcoded out own platform-specific logic to the reset database process. These could perhaps be moved to events also.