Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database Backup not working properly - metadata changes in between #422

Closed
olivermack opened this issue May 17, 2018 · 10 comments
Closed

Database Backup not working properly - metadata changes in between #422

olivermack opened this issue May 17, 2018 · 10 comments
Milestone

Comments

@olivermack
Copy link

I'm using 2.0.0-alpha4 with SQlite database tests. It seems as if the creation of the filename is inconsistent during test execution.

Given I'm running a single test with a single call to loadFixtures() with a single fixture on empty cache I can see that the result of \Liip\FunctionalTestBundle\Services\DatabaseBackup\SqliteDatabaseBackup::getBackupFilePath differs in isBackupActual() from backup(), thus he's checking a file that he won't write. I can imagine this is due to the way how the \Liip\FunctionalTestBundle\Services\DatabaseTools\AbstractDatabaseTool::getMetadatas() loads the metadata in contrast to the way how Doctrine is doing it under the hood.

In fact I've dumped the hashes multiple times and it changes indeed. Actually I was only able to get the backup+restore procedure running when changing the \Liip\FunctionalTestBundle\Services\DatabaseBackup\SqliteDatabaseBackup::getBackupFilePath() to hash only the serialize($this->classNames), without the metadata.

Is this reproducible for someone?

Best

alexislefebvre added a commit to alexislefebvre/LiipFunctionalTestBundle that referenced this issue May 26, 2018
@alexislefebvre
Copy link
Collaborator

I ran the test testBackupIsRefreshed() several times and only one backup file was created. I added some checks in #425 in order to ensure that the backup file was used successfully, and it worked.

maximgubar added a commit that referenced this issue Jun 11, 2018
@magnetik
Copy link
Contributor

I'm feeling the same but I'm currently failing to identify why.

I'm often loading no fixtures through $this->loadFixtures([]) in WebTestCase, but it's loading a backup with data in it.

@magnetik
Copy link
Contributor

Okay nevermind, it's due to my fix in #413 (to fix #411 that still need a solution).

@alexislefebvre
Copy link
Collaborator

@magnetik Can we close this issue?

@alexislefebvre alexislefebvre added this to the 2.0 milestone Jun 11, 2018
@magnetik
Copy link
Contributor

magnetik commented Jun 12, 2018

I'm using 2.0x branch extensively and I did not noticed this, so unless @olivermack still face it I think it can be closed.

@alexislefebvre
Copy link
Collaborator

I'm closing this issue for now. Feel free to reopen it if the problem is not solved.

@olivermack
Copy link
Author

@alexislefebvre I've just tested it again and I'm still facing the described issues...

  • liip/functional-test-bundle is at 3.2.0
  • liip/test-fixtures-bundle is at 1.3.0
  • doctrine/doctrine-fixtures-bundle is at 3.2.2

My fixtures are indeed ContainerAware, but do not have any constructor dependencies.
Please let me know if I can provide you with any additional details to help figuring out what the issue is. As I've wrote initially I was able to boil it down to the metadatas hash in the filename which changes in each execution.

@olivermack
Copy link
Author

Ah, maybe I found something... In some of my fixtures I'm using an AssignedGenerator IdGenerator to set a predefined ID (I'm using UUIDs as PKs). Those seem to cause some trouble. I've just diffed the VarDumper::dump()ed version of the metadatas used for backup and restore and surprisingly the diff output showed me exactly that... I'll see if I just forgot to reset the generator.
I'll let you know if it helped!

@olivermack
Copy link
Author

Yeah, ok, that was the issue indeed...
Let me quickly describe how I fixed it for me :)...

Most of my entities have an annotation-mapping defined like this:

/**
 * @ORM\Column(name="id", type="string", length=36)
 * @ORM\Id
 * @ORM\GeneratedValue(strategy="UUID")
 */
private $id;

In some of my fixtures I wanted to have a couple of items with predefined UUIDs, this I have something like this in the beginning of my fixture:

public function load(ObjectManager $manager)
{
    $metadata = $manager->getClassMetadata(MyEntity::class);
    $metadata->setIdGenerator(new \Doctrine\ORM\Id\AssignedGenerator());
    $metadata->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);

    $entity = new MyEntity();
    $entity->setId('00000000-0000-0000-2110-000000000000');

    // ...
}

Because of the fact that the fixtures are executed on a non-existent cache, the fixture's load() did actually change the metadata in between and therefore changed the md5 checksums... after I've added a reset at the end of those fixtures it worked:

public function load(ObjectManager $manager)
{
    $metadata = $manager->getClassMetadata(MyEntity::class);
    $metadata->setIdGenerator(new \Doctrine\ORM\Id\AssignedGenerator());
    $metadata->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);

    $entity = new MyEntity();
    $entity->setId('00000000-0000-0000-2110-000000000000');

    // ...

    $metadata->setIdGenerator(new \Doctrine\ORM\Id\UuidGenerator());
    $metadata->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_UUID);
}

Sorry for the confusion, it was actually my fault - but indeed tricky to find ;).

Best

@alexislefebvre
Copy link
Collaborator

Thanks for the detailed information. This could be interesting to document this in https://github.com/liip/LiipTestFixturesBundle/blob/master/doc/database.md or https://github.com/liip/LiipTestFixturesBundle/blob/master/doc/caveats.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants