Doctrine 1
  1. Doctrine 1
  2. DC-441

When using PearStyle model loading and a classPrefix, the Doctrine CLI will ignore any SQL operations if model_autoloading is set to conservative

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: 1.2.2
    • Component/s: Cli, Import/Export, Native SQL
    • Labels:
      None
    • Environment:
      Mac OS X, PHP 5.2.9

      Description

      When using PearStyle model loading and a classPrefix, the Doctrine CLI will ignore any SQL operations if model_autoloading is set to conservative . If model_autoloading is set to aggressive, then everything works as expected.

      Here's my Doctrine configuration:

      doctrine.generate_models_options.pearStyle = true
      doctrine.generate_models_options.generateTableClasses = false
      doctrine.generate_models_options.generateBaseClasses = true
      doctrine.generate_models_options.baseClassPrefix = "Base_"
      doctrine.generate_models_options.baseClassesDirectory =
      doctrine.generate_models_options.classPrefixFiles = false
      doctrine.generate_models_options.classPrefix = "Model_"
      ; Conservative Model Loading:
      doctrine.model_autoloading = 2

      and my Doctrine initialization method:
      protected function _initDoctrine()

      { $this->getApplication()->getAutoloader() ->pushAutoloader(array('Doctrine', 'autoload')); spl_autoload_register(array('Doctrine', 'modelsAutoload')); $doctrineConfig = $this->getOption('doctrine'); $manager = Doctrine_Manager::getInstance(); $manager->setAttribute(Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true); $manager->setAttribute( Doctrine::ATTR_MODEL_LOADING, $doctrineConfig['model_autoloading'] ); Doctrine::loadModels($doctrineConfig['models_path']); $conn = Doctrine_Manager::connection($doctrineConfig['dsn'],'doctrine'); $conn->setAttribute(Doctrine::ATTR_USE_NATIVE_ENUM, true); return $conn; }

      and my doctrine.php CLI file:

      require_once 'Zend/Application.php';

      // Create application, bootstrap, and run
      $application = new Zend_Application(
      APPLICATION_ENV,
      APPLICATION_PATH . '/configs/application.ini'
      );

      $application->getBootstrap()->bootstrap('doctrine');

      $config = $application->getOption('doctrine');
      $cli = new Doctrine_Cli($config);
      $cli->run($_SERVER['argv']);

        Activity

        Hide
        Owen Gray added a comment -

        I hope this is an appropriate place for these comments.

        I have been experimenting with the sort of ZF-Doctrine setup described by Jon. I find that everything does not work as expected with model-autoloading set to aggressive.

        If the models directory contains

        models/
        Address.php
        Base/
        Address.php
        User.php
        User.php

        operations like 'create-tables' will fail with an error message that says:

        "Fatal error: Class 'Model_Base_Address' not found in /path/to/models/Address.php"

        There is no error if the same operation on the same models is performed by a "pure Doctrine" CLI setup like the one in the Sandbox is used, with model-autoloading set to MODEL_LOADING_PEAR = 3. The difference is that in Jon's setup and mine, the Zend autoloader is registered before the Doctrine models autoloader. In this configuration, the Zend autoloader can find files with a 'Model_' prefix in the 'models' directory.

        When the Doctrine models autoloader loads a file it puts information about the file in Doctrine_Core::_loadedModelsFiles. It looks as though Doctrine_Core::loadModels and perhaps other cli operations rely on this, assuming that if a model file has been loaded, information about that file can be obtained from Doctrine_Core::_loadedModelsFiles. That won't be the case if the Zend autoloader loaded the file, as might occur if an instance of Address.php was created before the iterator in Doctrine_Core::loadModels got to Base/Address.php.

        The same problem occurs if doctrine.generate_models_options.baseClassPrefix is set to "Base." It does not occur if that parameter is set to "A" or "A/".

        I considered whether this problem might be related to the ZF unfriendly restriction referred to in http://www.doctrine-project.org/jira/browse/DC-277, because classPrefixFiles is set to 'false' as it has to be for the standard ZF configuration. However, perhaps serendipitously, the cli operations seem to work fine with that setting using the 'pure Doctrine' cli setup.

        I hope this information assists in sorting out this bug.

        Show
        Owen Gray added a comment - I hope this is an appropriate place for these comments. I have been experimenting with the sort of ZF-Doctrine setup described by Jon. I find that everything does not work as expected with model-autoloading set to aggressive. If the models directory contains models/ Address.php Base/ Address.php User.php User.php operations like 'create-tables' will fail with an error message that says: "Fatal error: Class 'Model_Base_Address' not found in /path/to/models/Address.php" There is no error if the same operation on the same models is performed by a "pure Doctrine" CLI setup like the one in the Sandbox is used, with model-autoloading set to MODEL_LOADING_PEAR = 3. The difference is that in Jon's setup and mine, the Zend autoloader is registered before the Doctrine models autoloader. In this configuration, the Zend autoloader can find files with a 'Model_' prefix in the 'models' directory. When the Doctrine models autoloader loads a file it puts information about the file in Doctrine_Core::_loadedModelsFiles. It looks as though Doctrine_Core::loadModels and perhaps other cli operations rely on this, assuming that if a model file has been loaded, information about that file can be obtained from Doctrine_Core::_loadedModelsFiles. That won't be the case if the Zend autoloader loaded the file, as might occur if an instance of Address.php was created before the iterator in Doctrine_Core::loadModels got to Base/Address.php. The same problem occurs if doctrine.generate_models_options.baseClassPrefix is set to "Base." It does not occur if that parameter is set to "A" or "A/". I considered whether this problem might be related to the ZF unfriendly restriction referred to in http://www.doctrine-project.org/jira/browse/DC-277 , because classPrefixFiles is set to 'false' as it has to be for the standard ZF configuration. However, perhaps serendipitously, the cli operations seem to work fine with that setting using the 'pure Doctrine' cli setup. I hope this information assists in sorting out this bug.
        Hide
        Jon Lebensold added a comment -

        Owen, thanks for bringing this up. I noticed the issue, as did a number of the people on zendcasts.com.

        Show
        Jon Lebensold added a comment - Owen, thanks for bringing this up. I noticed the issue, as did a number of the people on zendcasts.com.
        Hide
        Jonathan H. Wage added a comment -

        I don't see any issue/bug described here. If your classes are organized to be for PEAR style and you don't have it configured to work that way, then of course it is not going to work. That is expected.

        Show
        Jonathan H. Wage added a comment - I don't see any issue/bug described here. If your classes are organized to be for PEAR style and you don't have it configured to work that way, then of course it is not going to work. That is expected.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Jon Lebensold
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: