Doctrine 1
  1. Doctrine 1
  2. DC-137

Doctrine_Record_Generator does not autoload classes

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.0-ALPHA2
    • Fix Version/s: 1.2.0-BETA1
    • Component/s: Record
    • Labels:
      None
    • Environment:
      CentOS 5.3, PHP 5.2.5

      Description

      Using the versionable behavior creates dynamic classes and does not autoload the models that are defined. Removing the false flag from if ($this->_options['generateFiles'] === false && class_exists($this->_options['className']. false )) { line will fix the issue

        Activity

        Hide
        Jonathan H. Wage added a comment -

        Doesn't the autoloader have an option to check if the file exists before trying to include it?

        Show
        Jonathan H. Wage added a comment - Doesn't the autoloader have an option to check if the file exists before trying to include it?
        Hide
        Joël added a comment -

        Hi !

        I'm using Zend Framework and Doctrine and I got warnings with Doctrine_Template_Searchable that was trying to load the Index classes of the Searchable behaviour.
        And as you said, with the false argument of get_class() Zend_Framework failed...

        I tried with 1.9.6 of Zend_Framework and it still failed, although they seem to say in your external reference ([ZF-8364] Zend_Loader_Autoloader_Resource::autoload() should return false if no match is found) that it would be fixed in release 1.9.6...

        Here it is... it was just to point it out

        Show
        Joël added a comment - Hi ! I'm using Zend Framework and Doctrine and I got warnings with Doctrine_Template_Searchable that was trying to load the Index classes of the Searchable behaviour. And as you said, with the false argument of get_class() Zend_Framework failed... I tried with 1.9.6 of Zend_Framework and it still failed, although they seem to say in your external reference ( [ZF-8364] Zend_Loader_Autoloader_Resource::autoload() should return false if no match is found) that it would be fixed in release 1.9.6... Here it is... it was just to point it out
        Hide
        Adam Jensen added a comment -

        For what it's worth, I'm running r6785 of the http://svn.doctrine-project.org/tags/1.2.0-BETA3 tag, and the absence of the false argument is causing me some annoying issues.

        Based on the documentation/parameters/etc., I'm assuming both of the following use cases are supposed to be possible:

        A. The ModelNameVersion class is generated on-the-fly as necessary, and never stored in the filesystem.
        B. The ModelNameVersion class is generated once, stored in the filesystem, and subsequently autoloaded from there.

        Now, from what I can tell, both use cases work correctly even without the false argument on line 159; however, in case A, a PHP warning can be generated if one of the registered autoloaders doesn't check to see if the file exists before including it. This appears to be the case with Zend_Loader_Autoloader_Resource, for instance; my guess is that it's designed that way such that non-existing files produce the same warnings you'd get if you tried to include them manually ...but it doesn't play nice with Doctrine's expectations here (and heck, it may well be a bug on their part to write it that way).

        These warnings don't appear to affect any functionality ...the line 159 conditional still turns up false, allowing the class to be generated on the fly. All the same, I'd prefer not to have to turn off E_WARNING on my development machine just to avoid seeing these. Since Doctrine can't really guarantee that all of the autoloaders registered with SPL are properly avoiding such blind includes, it may make more sense to leave the false argument in place and avoid the warnings.

        Of course, I don't know what effect that would have on use case B; my guess is that it'd break, since that's what this issue was originally about Is there another solution available that satisfies both use cases without raising any errors?

        Thanks!
        Adam

        Show
        Adam Jensen added a comment - For what it's worth, I'm running r6785 of the http://svn.doctrine-project.org/tags/1.2.0-BETA3 tag, and the absence of the false argument is causing me some annoying issues. Based on the documentation/parameters/etc., I'm assuming both of the following use cases are supposed to be possible: A. The ModelNameVersion class is generated on-the-fly as necessary, and never stored in the filesystem. B. The ModelNameVersion class is generated once, stored in the filesystem, and subsequently autoloaded from there. Now, from what I can tell, both use cases work correctly even without the false argument on line 159; however, in case A, a PHP warning can be generated if one of the registered autoloaders doesn't check to see if the file exists before including it. This appears to be the case with Zend_Loader_Autoloader_Resource, for instance; my guess is that it's designed that way such that non-existing files produce the same warnings you'd get if you tried to include them manually ...but it doesn't play nice with Doctrine's expectations here (and heck, it may well be a bug on their part to write it that way). These warnings don't appear to affect any functionality ...the line 159 conditional still turns up false, allowing the class to be generated on the fly. All the same, I'd prefer not to have to turn off E_WARNING on my development machine just to avoid seeing these. Since Doctrine can't really guarantee that all of the autoloaders registered with SPL are properly avoiding such blind includes, it may make more sense to leave the false argument in place and avoid the warnings. Of course, I don't know what effect that would have on use case B; my guess is that it'd break, since that's what this issue was originally about Is there another solution available that satisfies both use cases without raising any errors? Thanks! Adam
        Hide
        Brian Voelschow added a comment -

        If your tests are not passing then there must be a reason for it to be set to false. I think a configuration option here would be a better solution. Similar to the Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES setting.

        Show
        Brian Voelschow added a comment - If your tests are not passing then there must be a reason for it to be set to false. I think a configuration option here would be a better solution. Similar to the Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES setting.
        Hide
        Jonathan H. Wage added a comment -

        We'll give this change a try. If it causes some issues for people we may have to revert it. I remember that false argument being there for a reason but I can't remember and none of our tests pass without it.

        Show
        Jonathan H. Wage added a comment - We'll give this change a try. If it causes some issues for people we may have to revert it. I remember that false argument being there for a reason but I can't remember and none of our tests pass without it.

          People

          • Assignee:
            Jonathan H. Wage
            Reporter:
            Brian Voelschow
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: