Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
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()
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']);
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.