Doctrine_Parser_Yml dependany on sfYaml causing issues for non symfony users

I could not get your 'quick fix' to work no matter whether i dumped the files in the parser dir, on my include path or anywhere.

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.

Hi Ashley

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

I will fix the issue first thing this week. @Ashley, this is the way it used to be before this change. The issue is then we don't get bug fixes from sfYaml. It is better if we use it as a vendor library.

I moved the sfYaml external folder to the Parser folder. This should work better for everyone now.

It's nice that one can now skip to add

/library/Doctrine

to the included paths, but it's not so nice that now the sfYaml files can not be found.

This ticket is not fixed. The doctrine autoloader should handle all it's dependencies, including those from symphony. These kind of things should not leak outside doctrine.

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

hmm, What is the problem? The Doctrine::autoload() function does handle the autoloading of sfYaml now. Can you explain more detail about the problem you are encountering?

I had a problem too in it nit being handled by the autoloader. It may be down to how I have integrated Doctrine into my Zend Framework app, so I cant really comment on that one

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

What was the problem? What was the error you got? I'd like to try and help fix something in Doctrine to make this handled better so any other more specific information anyone can provide would be much appreciated.

In an Application using Zend Framework 1.9.6 and Doctrine 1.2,

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

Why is that "workaround" ugly? The fact of the matter is that not all code that is useful follows the same naming conventions. Having to fork or write wrappers around code with different naming conventions is a maintenance nightmare. Doctrine's autoloader implementation is a reference implementation but I assume most people use their own (by way of their chosen framework) and that one better be flexible enough to deal with different naming conventions. It seems ZF has these capabilities, so why is it ugly using them?

I see, so the problem is when you're not using Doctrine::autoload(). The thing is we seem to have problems no matter how we integrate sfYaml. Originally we had it setup as Doctrine_Parser_Yaml_SfYaml so it was just like a normal Doctrine class, but then it got out of date and we don't get the latest bug fixes. I changed it to be in lib/vendor/sfYaml and required it manually in the Doctrine code that used it. This causes problems if the project has already loaded sfYaml by other means. For example in a Symfony project sfYaml exists sometimes or if the user happens to use the sfYaml component in his project. So, it needs to be handled by the autoloader for sure I think.

Edit: Looks like having this:

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

Currently using ZF 1.10 and Doctrine 1.2.1. To resolve this issue you need to ask Zend's Autoloader to register Doctrine's Autoloader for Doctrine and sfYaml namespaces:

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