Creación de la clase de usuario

Since I haven't found a solution yet. I just doing a work-around:

[ ] Run any migrations needed.
[ ] Export the "doctrine_migrations_versions" table.
[ ] Run the foundry:load-fixtures command
[ ] Import the "doctrine_migrations_versions" table.

Sigh...

So I tried adding the reset mode migrate to the zenstruck_foundry.yaml

when@dev: &dev
    # See full configuration: https://symfony.com/bundles/ZenstruckFoundryBundle/current/index.html#full-default-bundle-configuration
    zenstruck_foundry:
        persistence:
            # Flush only once per call of `PersistentObjectFactory::create()`
            flush_once: true
        orm:
            reset:
                mode: migrate # enables resetting with migrations

But now I get a transaction error.

It will save the first User and then die with the error:

In ExceptionConverter.php line 102:
  An exception occurred while executing a query: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_2 does not exist  

In Exception.php line 24:
  SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_2 does not exist  

In Connection.php line 27:
  SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_2 does not exist  
                                                                                               
In UnitOfWork.php line 446:
  Commit failed  
                 
In ExceptionConverter.php line 102:
  An exception occurred while executing a query: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_3 does not exist  

In Exception.php line 24:
  SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_3 does not exist  
                                                                                               
In Connection.php line 27:
  SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_3 does not exist  

Something is closing the transaction. Not sure how the reset mode would have messed with that.

Not sure what to do next. There is someting about a migrate configuration file, but I haven't found anything clear yet.

Hey @JeffJones!

Ok, yeah, the migrate mode was the solution to your original problem. Let's see if we can figure out this new one. It is known to me but it's been a bit illusive to track down a proper cause.

Here is the workaround we've found. In each of your migrations, add:

public function isTransactional(): bool
{
    return false;
}

To always have this added, you can configure it:

doctrine_migrations:
    transactional: false

Let me know if that works. I am not 100% sure why this is needed. It isn't required for all DB platforms (sqlite for instance).
By the way, in Foundry, we don't default to migrate mode because it can get quite expensive to reset your database when you have dozens or hundreds of migrations. As long as your migrations don't do anything fancy that the drop/create schema operations can't do, schema mode is the faster choice.

Of course, you still need to know your migrations are current/correct. I've done this in a CI job:

php bin/console doctrine:database:drop --force --if-exists
php bin/console doctrine:database:create
php bin/console doctrine:migrations:migrate --no-interaction
php bin/console doctrine:schema:validate

doctrine:schema:validate will fail if there are differences between the database and your defined schema.

Anyway, let me know how you make out!
Kevin

I was kind of hoping that Foundry had something similar to:

 doctrine:fixtures:load --purge-exclusions=doctrine_migrations_versions

Or even maybe something in the configuration to exclude tables. I believe Doctrine has a way to create your own Purger class so you can control it. Does Foundry have something like that?

All I could find, so far, are the classes in the ORM/ResetDatabase folder. I would have to replace the dropAndResetDatabase method which is final. Not sure how I'd wire in a replacement class.

Yeah, purging is something we haven't experimented with on Foundry. I think we investigated but it's complex.

BTW, it's totally valid to use normal doctrine fixtures with foundry. In your data fixtures just create factories or load stories. It was the only method to do so for many years. Foundry's load-fixtures command is relatively new. We added it because requiring doctrine fixtures brings a lot of unused code just to load foundry factories.

Wow! Thanks!

The first suggestion, having the isTransactional return false, works perfectly.

public function isTransactional(): bool
{
    return false;
}

Though as you mentioned migrations can slow done things like testing. Something I will have to keep mind.

The second suggestion, adding transactional:false to doctrine_migrations in the doctrine_migrations.yaml, for some reason did not work. It gives the same error, so the configuration is not working. I could only get it to work with the "isTranasactional" method.

doctrine_migrations:
    transactional: false

Again, thanks! I'm back on track!

Awesome, I'm glad that worked!

For the config, I believe all that does is make future generated migration classes add that method. So going forward, you don't have to manually add it to every migration.

Ah! Nice. Sounds good!

@Brontie

Hey @giorgiocba

This may sound silly, but did you load the fixtures? symfony console foundry:load-fixtures
If you did, could you do it again and see if there were any errors or warnings?
Another thing to check is whether you're using Docker for the database and whether you have it installed locally. It may be the case that the CLI is using the Docker instance, but the web isn't.

Cheers!

What could have happened?