Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Incomplete
-
Affects Version/s: 1.2.1
-
Fix Version/s: None
-
Component/s: Cli, Extensions, Record
-
Labels:None
-
Environment:Linux skywalker-9 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux
Description
When using Doctrine_Record_Generator to generate a related model and the option 'generateFiles' is set to false, the class variable _table is not set during initialize(), which then causes getTable() to return null.
However, getTable() is necessary when moving columns between the original model and the newly created model, or other similar tasks (which is why you would want to use Doctrine_Record_Generator in the first place!!)
Reproducing this bug is pretty difficult, but here's how you do it:
- create a template that uses a concrete implementation of Doctrine_Record_Generator to do some work during template->setUp()
- during template->setUp(), call $this->_plugin->initialize($this->_table), where $this->_plugin is the concrete record generator.
- after calling initialize(), call $this->_plugin->getTable() and do something with the result (for instance, echo $this->_plugin->getTable()->getComponentName() )
- now, use this template in two separate environments: one where the generator option 'generateFiles' is set to false, and one where it is set to true.
The problem is that in an environment where you do not need to generate files (i.e. unit testing), you no longer have access to the newly created table via $this->_plugin->getTable().
The solution is to still set up the _table object, but not generate the class file, when 'generateFiles' is set to false or when the class definition is already loaded.
Patch is attached.
This patch breaks the test suite and the issue does not include any reproducible test case for me to run so i can see the problem myself.