[#DC-126] Doctrine_Migration_Diff breaks on inherited class

Doctrine 1

Doctrine_Migration_Diff breaks on inherited class

Created: 20/Oct/09 06:18 PM Updated: 29/Mar/10 01:29 PM

Component/s:

Migrations

Affects Version/s:

1.2.0-ALPHA1, 1.2.0-ALPHA2

Fix Version/s:

1.2.1

Environment:

php 5.3 / symfony 1.3

Description

« Hide

This ticket is a duplicate of this one http://trac.symfony-project.org/ticket/7272 but it's more a Doctrine bug than a symfony one.

When trying to make a diff on schema with inheritance, the task breaks when trying to load a model inherited from an other one. I think this is because the inherited model might be loaded before his ancestor.

All

Comments

Change History

FishEye

Sort Order:

[ Permalink | « Hide ]

Jonathan H. Wage added a comment - 20/Oct/09 06:39 PM

test case? any code to duplicate?

[ Permalink | « Hide ]

Marc Weistroff added a comment - 20/Oct/09 06:47 PM

First a patch which is more a proof of concept...
It's getting late here and will code the test case tomorrow

[ Permalink | « Hide ]

Marc Weistroff added a comment - 21/Oct/09 08:23 AM - edited

I'm having difficulties to prove it with the Doctrine Sandbox... Because it works fine in this case... :'(
I past the error log, it might be helpful:

stlto28:www marc$ php symfony doctrine:generate-migrations-diff
>> doctrine  generating migration diff
>> file+     /private/var/folders/vu/vuQEAsRN...-Tmp-/doctrine_schema_IRajfY.yml
PHP Fatal error:  Class 'ToPrfxuvmcCmsContent' not found in /private/var/folders/vu/vuQEAsRNGECmKgHPU7Y1vk+++TI/-Tmp-/toprfx_doctrine_tmp_dirs/ToPrfxuvmcCmsArticle.php on line 15
PHP Stack trace:
PHP   1. {main}() /myProject/symfony:0
PHP   2. include() /myProject/symfony:14
PHP   3. sfSymfonyCommandApplication->run() /myProject/lib/vendor/symfony/lib/command/cli.php:20
PHP   4. sfTask->runFromCLI() /myProject/lib/vendor/symfony/lib/command/sfSymfonyCommandApplication.class.php:76
PHP   5. sfBaseTask->doRun() /myProject/lib/vendor/symfony/lib/task/sfTask.class.php:97
PHP   6. sfDoctrineGenerateMigrationsDiffTask->execute() /myProject/lib/vendor/symfony/lib/task/sfBaseTask.class.php:67
PHP   7. sfDoctrineBaseTask->callDoctrineCli() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/task/sfDoctrineGenerateMigrationsDiffTask.class.php:65
PHP   8. Doctrine_Cli->run() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/task/sfDoctrineBaseTask.class.php:64
PHP   9. Doctrine_Cli->_run() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Cli.php:148
PHP  10. Doctrine_Task_GenerateMigrationsDiff->execute() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Cli.php:210
PHP  11. Doctrine_Migration_Diff->generateMigrationClasses() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Task/GenerateMigrationsDiff.php:48
PHP  12. Doctrine_Migration_Builder->generateMigrationsFromDiff() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Diff.php:111
PHP  13. Doctrine_Migration_Diff->generateChanges() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Builder.php:147
PHP  14. Doctrine_Migration_Diff->_diff() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Diff.php:99
PHP  15. Doctrine_Core::loadModels() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Diff.php:125
PHP  16. require_once() /myProject/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Core.php:649

[ Permalink | « Hide ]

Marc Weistroff added a comment - 21/Oct/09 12:39 PM

I tryed to reproduce the failing case in a doctrine sandbox but the task is executed just fine... So I tried with a Symfony sandbox and it failed.
I guess there is some kind of autoloading incompatibility somewhere.

I uploaded a sandbox on symfony's trac with the failing schema. The ticket is viewable here http://trac.symfony-project.org/ticket/7272

Thanx

[ Permalink | « Hide ]

Jonathan H. Wage added a comment - 18/Nov/09 10:03 PM

This issue cannot be reproduced and no new information has been given.

[ Permalink | « Hide ]

Alex Gilbert added a comment - 02/Dec/09 08:01 PM

I am having this problem as well.

>> doctrine generating migration diff
>> file+ /private/var/folders/uO/uOcfxzTRGA8G6XQvExbGF++++TI/~~Tmp~~/doctrine_schema_87129.yml

Fatal error: Class 'ToPrfxpkContextCMSSlot' not found in /private/var/folders/uO/uOcfxzTRGA8G6XQvExbGF++++TI/~~Tmp~~/toprfx_doctrine_tmp_dirs/ToPrfxpkContextCMSButtonSlot.php on line 14

{/code}

The most recent activity on this issue seems to be in the symfony Trac, where Jon said work would be continued in here, but this ticket is also closed. I don't know Jira as well, is there a way to re-open this ticket? Is there an active clone of it somewhere?

Thanks.

[ Permalink | « Hide ]

Tom Boutell added a comment - 07/Dec/09 06:40 PM

Reproducible test case:

[Remove your toprfx_doctrine_tmp_dirs etc. from your tmp folder, leftover classes from earlier crashes can cause unrelated errors, see separate ticket]

svn co http://svn.symfony-project.com/plugins/pkContextCMSPlugin/sandbox/branches/1.3 cmstest13
cd cmstest13
Create config/doctrine/schema.yml and add a trivial table so another bug won't be triggered (I opened a separate ticket on that):

Frog:
columns:
name: string

./symfony doctrine:build --all
./symfony doctrine:generate-migrations-diff

Fatal error: Class 'ToPrfxpkContextCMSSlot' not found in /private/var/folders/3H/3Hu3TTyjFtuvtN3D5tDUxU+++TI/~~Tmp~~/toprfx_doctrine_tmp_dirs/ToPrfxpkContextCMSButtonSlot.php on line 15

Note that pkContextCMSButtonSlot inherits from pkContextCMSSlot using Doctrine column aggregation inheritance. It appears that the autoloader just isn't trying to resolve inheritance relationships between classes in the toprfx_doctrine_tmp_dirs folder.

[ Permalink | « Hide ]

Robert Gruendler added a comment - 14/Feb/10 03:23 PM

i've created a patch which fixes the issue, it's attached to the corresponding symfony ticket:

http://trac.symfony-project.org/ticket/7272

It modifies the core autoloading code and i'm not really familiar with the doctrine autoloading code, so please let me know if this
approach can be approved.

[ Permalink | « Hide ]

Jonathan H. Wage added a comment - 29/Mar/10 01:20 PM

Hi, the patch cannot be committed. It is a blatant hack and cannot be applied. I have a solution I will commit soon though.

[ Permalink | « Hide ]

Jonathan H. Wage added a comment - 29/Mar/10 01:29 PM

This should be fixed now: http://trac.symfony-project.org/changeset/28871

Thanks, Jon