Doctrine 1
  1. Doctrine 1
  2. DC-288

Doctrine_Parser_Yml dependany on sfYaml causing issues for non symfony users

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.0
    • Fix Version/s: 1.2.0
    • Component/s: File Parser
    • Labels:
      None

      Description

      I am currently undergoing an integration with the Zend Framework. Unfortunatly we do not use the Symfony framework and have no scope available to include it.

      The requirement for sfyaml in its rawest form has caused me to have to rewrite part of your parser to ensure it includes the crrect files which I have now included in our working version of Doctrine.

      As Symfony appears to be distributed under an open license surely it would make sense for you to actually include this (or a modified version of this) into your library.

      This would make the code much more portable and reusable for people who do not use symfony

      My "Quick Fix" just involved dropping all the sfYaml files into the parser folder and doing a straight include untill I can find a more elegant solution

        Activity

        Hide
        Peter Petermann added a comment - - edited

        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.

        Show
        Peter Petermann added a comment - - edited 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.
        Hide
        Lukas Kahwe added a comment -

        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?

        Show
        Lukas Kahwe added a comment - 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?
        Hide
        Jonathan H. Wage added a comment -

        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.

        Show
        Jonathan H. Wage added a comment - 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.
        Hide
        Jeremy Hicks added a comment - - edited

        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.

        Show
        Jeremy Hicks added a comment - - edited 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.
        Hide
        Michael Ekoka added a comment -

        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'));

        Show
        Michael Ekoka added a comment - 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'));

          People

          • Assignee:
            Jonathan H. Wage
            Reporter:
            Matt Cockayne
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: