Would it not be a good idea to reformat the sfYaml class names into the Pear/Zend/Doctrine scheme and integrate them into doctrine it's self?

for example:
File name:
sfYaml.php -> Doctrine/Parser/Yaml.php
Class name:
sfYaml -> Doctrine_Parser_Yaml

File name:
sfYamlDumper.php -> Doctrine/Parser/Yaml/Dumper.php
Class name:
sfYamlDumper -> Doctrine_Parser_Yaml_Dumper

etc...

If these files are going to be used as standard i would think it to be a good idea.

This link will show you how I added the files to create my quick fix from the files stored in my subversion repo.

http://subversion.zucchi.co.uk/listing.php?repname=titan&path=%2Ftrunk%2Flibrary%2FDoctrine%2FParser%2F#path_trunk_library_Doctrine_Parser_

As well as puutting the files in the parser dir I also had to change the requires at the top of the yaml.ph file.

Changeing the names of the classes would be a good idea for a more permanent fix but I will leave that to the good people at Doctrine to decide to put in place

It took me quite some time to figure out. It is a severe bug.

the problem is easily fixed with a simple set of requires in the parser file. not ideal but it works for the moment

$ doctrine-cli generate-models-yaml
PHP Fatal error: Class 'sfYaml' not found in /path/to//library/Doctrine/Doctrine/Parser/Yml.php on line 80
Fatal error: Class 'sfYaml' not found in /path/to/library/Doctrine/Doctrine/Parser/Yml.php on line 80

further investigation shows that the method in Core.php, which was modified with the new Path is never called.

the thing is, usually one sets up Zend Framework, so it uses the Doctrine autoloader
whenever a class is prefixed with Doctrine (by registering that namespace)
however, since sfYaml doesnt fall under that rule, the Zend Autoloader does not know that it needs to forward this, therefor the Doctrine one is never called.

A workarround is to add
require_once 'Doctrine.php';
$autoloader = Zend_Loader_Autoloader::getInstance();
$autoloader->registerNamespace('sfYaml')->pushAutoloader(array('Doctrine', 'autoload'), 'sfYaml');
to the Zend Booststrap class - like in your _initDoctrine method.

This, tbfh, is still an ugly workarround, but so is the sfYaml loading in the doctrine autoloader itself. Personally i agree with the OP, Doctrine should come as a complete package, not using symfony externals.

$manager->setAttribute(
Doctrine::ATTR_MODEL_LOADING,
Doctrine::MODEL_LOADING_CONSERVATIVE
);

in an Application Resource plug-in along with the CLI call stops the tables from getting created.

Autoloading the sfYaml stuff works for me now, but I'm having what appears to be a related problem. The Doctrine cli task "build-all-reload" is supposed to both recreate the database and generate the model files. It is generating the model files fine now. However, the database gets dropped and re-added, but none of the tables get re-added. The output says, "Created tables successfully" but after checking the DB they are not there. I'm using an application resource class, not a bootstrap init function, if that matters.

$loader = Zend_Loader_Autoloader::getInstance();
$loader->pushAutoloader(array('Doctrine_Core','autoload'), array('Doctrine', 'sfYaml'));