mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-2134: Add referential integrity check for MySQL to console commands #2686
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Nov 9, 2012).
Originally assigned to: @Ocramius on GitHub.
Jira issue originally created by user holtkamp:
Today I spent some time solving a PHP 'White Screen of Death'. I traced it back to a Entity of which the proxy's __load() function was invoked because af a EXTRA_LAZY association. Due to incorrect database contents (the entry ID was changed due to an update: referential integrity broke), the __load() query resulted in no results. The EntityNotFoundException did for some reason not show up in our logs, probably because the lazy load was triggered by a magic __toString() function.
The cause is because of the way we populate or tables with domain data:
MySQL does not trigger any errors when the foreign key checks are turned back on, leaving the table in an inconsistent state.
To prevent this, I found some information in this post: http://www.mysqlperformanceblog.com/2011/11/18/eventual-consistency-in-mysql/, which I used to come with the following queries
By running the generated queries, we can now easily find the records that break referential integrity.
It might be an idea of adding this functionality to the orm:validate-schema, or a new orm:validate-database-integrity?
@marcobuschini commented on GitHub (Jul 7, 2016):
I love this idea! May I try, and work on implementing it?
@Ocramius commented on GitHub (Jul 7, 2016):
@marcobuschini this seems to be mysql-specific, so it wouldn't be merged into doctrine2. I suggest writing an external tool that acceots a doctrine schema instance or a PDO/DBAL connection
@marcobuschini commented on GitHub (Jul 7, 2016):
@Ocramius what you say seems so obvious that I forgot to mention it in my previous post.
I think everything can be done in a database agnostic way using Doctrine documentation at http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-manager.html but I didn't study that documentation, yet.
@marcobuschini commented on GitHub (Jul 9, 2016):
@Ocramius Ok, I wrote the code to do that using Doctrine APIs instead of db specific queries. On a first analysis it works on a simple case. I tried to follow the contributing guides for properly integrating my changes before going on, but I fail at installing d51PearPkg2Task because the URL reported in the documentation http://pear.domain51.com/svn/Phing_d51PearPkg2Task/trunk/src/phing/tasks/ext/d51PearPkg2Task.php appears to be no longer available. How can I build Doctrine without it?
@Ocramius commented on GitHub (Jul 11, 2016):
@marcobuschini where are you finding this stuff? Running DBAL tests is basically just
composer update+./vendor/bin/phpunit.@marcobuschini commented on GitHub (Jul 11, 2016):
@Ocramius the guide that I am following to write a patch (at http://www.doctrine-project.org/contribute.html) mentions the
phingtool in the Basic Build section, and it fails with:Of course now I understand that I am missing something about the build process.
@Ocramius commented on GitHub (Jul 11, 2016):
@marcobuschini I'll check where this is and remove it from the docs: evidently it's outdated :-)
@Ocramius commented on GitHub (Jul 11, 2016):
Reported at https://github.com/doctrine/doctrine-website-sphinx/issues/130
@Ocramius commented on GitHub (Sep 7, 2016):
Closing: won't be implemented in core (see #5964)