doctrine:generate-migrations-diff fails when using inheritance

The probleme comes from Doctrine. I created a ticket on Doctrine's Jira. http://www.doctrine-project.org/jira/browse/DC-126

After trying to reproduce the bug in a doctrine 1.2 sandbox & Symfony 1.3 sandbox, it appears that the bug only appears with symfony.

My guess is that there is an autoloading conflict somewhere...

I attach a symfony 1.3 sandbox wich will fail when running php symfony doctrine:generate-migrations-diff.

sf1.3 sandbox with failing schema

+1 here !

I change the priority to Major because symfony 1.3 has a better way of handling inheritance. Being able to migrate is critical! Thanx

I'm also seeing this behavior with a single level of inheritance.

Will work on this issue from Doctrine Jira.

The Jira ticket is closed as well... what is the definitive source for activity on this issue? I'm having the problem also:

>> 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

Thanks.

Excuse me but i don't understand why this ticket was closed.

I see DC-327 and DC-126. Both are marked as resolved (invalid & cannot reproduce).

I have the same problem. This is critical. Here is how to reproduce it:

1. Download the symfony 1.4.1 sandbox: http://www.symfony-project.org/get/sf_sandbox_1_4.tgz

2. Use the schema.yml shown in the symfony table inheritance documentation: http://www.symfony-project.org/advent_calendar/14/en

3. Build the project running "php symfony doctrine:build --all"

4. Run "php symfony doctrine:generate-migrations-diff"

It fails. You get "Fatal error: Class 'ToPrfxPerson?' not found in /tmp/toprfx_doctrine_tmp_dirs/ToPrfxStudent.php on line 14"

I reopen the bug here because in Doctrine Jira, some say this works fine with Doctrine without symfony: http://www.doctrine-project.org/jira/browse/DC-126

nthing that this is a real bug

It seems to be the autoloading problem mentioned by futurecat. All the registered autolaoders seems to ignore the temporary directory. I added the last two lines of the following snippet as a workarround in:

symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Migration/Diff.php

      protected function _generateModels($prefix, $item)
      {
          $path = sys_get_temp_dir() . DIRECTORY_SEPARATOR . strtolower($prefix) . '_doctrine_tmp_dirs';
          set_include_path( get_include_path() . PATH_SEPARATOR . $path);
          spl_autoload_register( 'spl_autoload');

Another workaround, perhaps less intrusive than the one proposed by MisterF would be to create/edit config/autoload.yml with the following content:

autoload:
  tmp:
    name:      tmp
    path:      /tmp
    recursive: true

Once the migration is done, I believe it's safer and better to comment these lines out, though.

I've hit this same issue - exactly as described above. I have one model that extends another via column_aggregation. Both models ARE generated correctly in the tmp directory, but the child model class is loaded first.

The autoload.yml solution works very nicely - thanks jean-gui.

I've had the same problem but the solutions mentioned here work on my more simple sites but don't seem to work with larger, more complicated projects. I've spent a lot of time in the debugger trying to work out what the problem is, but I've only managed to find out that there are some models generated after the autoload is re-initialised. Sorry I can't be more specific, but hopefully this information can help in some way.

It's probably safer to only autoload the /tmp/fromprfx_doctrine_tmp_dirs/ and /tmp/toprfx_doctrine_tmp_dirs/, especially on a shared server

Replying to jean-gui:

Another workaround, perhaps less intrusive than the one proposed by MisterF would be to create/edit config/autoload.yml with the following content: {{{ autoload: tmp: name: tmp path: /tmp recursive: true }}} Once the migration is done, I believe it's safer and better to comment these lines out, though.

Replying to ollietb:

It's probably safer to only autoload the /tmp/fromprfx_doctrine_tmp_dirs/ and /tmp/toprfx_doctrine_tmp_dirs/, especially on a shared server

Well, in my case temporary model files are stored in /tmp/<random_4digit_number>/fromprfx_doctrine_tmp_dirs/. So adding whole /tmp dir into autoload.yml caused lots of warnings, because some directories in my /tmp were not accessible for current user.

BTW, these temporary directories are not cleaned after migration, so adding them all to autoload looks very bad idea to me.

Good news, everyone!

the following snippet looks the best solution:

autoload:
  tmp:
    name:      tmp
    path:      /tmp/<?php echo getmypid()?>/toprfx_doctrine_tmp_dirs
    recursive: true

It autoloads only classes generated by current migration process. And, of course, no warnings, no fatal errors — everything goes clean.

Environment: Ubuntu 9.10, php 5.2.10, symfony 1.4 in PEAR.

Replying to jean-gui:

Another workaround, perhaps less intrusive than the one proposed by MisterF would be to create/edit config/autoload.yml with the following content: {{{ autoload: tmp: name: tmp path: /tmp recursive: true }}} Once the migration is done, I believe it's safer and better to comment these lines out, though.

Replying to develop7:

Good news, everyone! the following snippet looks the best solution: {{{ #!yml autoload: tmp: name: tmp path: /tmp/<?php echo getmypid()?>/toprfx_doctrine_tmp_dirs recursive: true }}}

Actually, this is not the best solution, because the autoload cache is kept after the migration command and even any in-between triggered symfony task will re-generate it and insert its own, bogus PID. The workaround for _this_ is to remove

$ rm -f cache/<appname>/<env>/config/config_autoload.yml.php

none of the above workarounds seem to work on OSX (10.6.1).

The tmp files under osx are generated in this folder:

/private/var/folders/8X/8XcjGvwEGKeUcmwvDdzkS++++TI/-Tmp-

so i created a config/autoload.yml like this:

autoload:
  tmp:
    name:      tmp
    path:      /private/var/folders/8X/8XcjGvwEGKeUcmwvDdzkS++++TI/-Tmp-/<?php echo getmypid()?>/toprfx_doctrine_tmp_dirs
    recursive: true

cleared the cache, but get the same error when running the migrations diff task.

Anyone tried this workaround on osx?

Patch

i've attached 3 patches which fix the issue.

Doctrine_Core.php:

* added member variable migration_tmp_path with getter and setter

* if migration_tmp_path is set in the static autoload callback, check there too for classes

Doctrine_Migration_Diff.php:

* added getters for _fromPrefix and _toPrefix

sfDoctrineGenerateMigrationsDiffTask.class.php:

setting Doctrine_Core::setMigrationTmpPath(sys_get_temp_dir() . DIRECTORY_SEPARATOR . getmypid()) before executing the task, so the classes can be loaded

Not sure if there are any performance penalties because i altered the autoloading code, but as it's only done when _migration_path is set, it should be fine i think.

i'd be glad for feedback / suggestions about the patch.

pulse00, consider adding sfDoctrineGenerateMigrationsDiffTask.class.php.patch to your patchset. It clears temp files after generating migration and reloads autoload (to prevent bogus effect described in 20)

Replying to pulse00:

i've attached 3 patches which fix the issue. Doctrine_Core.php: * added member variable migration_tmp_path with getter and setter
* if migration_tmp_path is set in the static autoload callback, check there too for classes Doctrine_Migration_Diff.php: * added getters for _fromPrefix and _toPrefix sfDoctrineGenerateMigrationsDiffTask.class.php: setting Doctrine_Core::setMigrationTmpPath(sys_get_temp_dir() . DIRECTORY_SEPARATOR . getmypid()) before executing the task, so the classes can be loaded Not sure if there are any performance penalties because i altered the autoloading code, but as it's only done when _migration_path is set, it should be fine i think. i'd be glad for feedback / suggestions about the patch.

symfony patch

i've created 2 patches, one for symfony and one for doctrine. The symfony patch has the patch from develop7 included. Doctrine patch is attached to the corresponding doctrine ticket: http://www.doctrine-project.org/jira/browse/DC-126

doctrine patch

couldn't find a way to attach a file to the doctrine issue tracker, so i attached it here...

correct doctrine patch

please disregard the first doctrine patch, it contained a typo. the last one is the correct one.

Replying to pulse00:

please disregard the first doctrine patch, it contained a typo. the last one is the correct one.

This patch doesn't work correctly on case-sensitive file systems - the migration class strtolower()'s the prefix when building the generated class path - this has been fixed. I also set a sane default for the $_migration_tmp_path member and let Doctrine_Migration_Diff use that as well instead of the plain sys_get_temp_dir() call.

With the disclaimer that I didn't look through the code, applying only the latest patch to doctrine by tommyd worked for me on a large project.

While the patch works, we can't commit this. Could we possibly make another autoloader that migrations uses to load those classes? or can we just require all of them manually?

(In [28871]) [1.3, 1.4] Fixing issue with migrations diff autoloading (fixes #7272)

I think this last commit should help with the issue and fix it once and for all!

This worked perfectly.

I'm using symfony version 1.4.10-DEV and I still have this problem:

PHP Fatal error:  Class 'ToPrfxsfGuardUserProfile' not found in /tmp/3746/toprfx_doctrine_tmp_dirs/ToPrfxRappresentante.php on line 21

I'm unable to create migrations script with doctrine:generate-migrations-diff task.

My project use two connection on two different databases and I'm using also concrete inheritance between sfGuardUserProfile and two distinct user profiles that extend it.

Using solution proposed by jean-gui fix the problem for me. I just created autoload.yml in app/frontend/config directory with:

autoload:
  tmp:
    name:      tmp
    path:      /tmp
    recursive: true