You're in the army now
Zend In- Doctrine -ation
So I’ve been using The framework and Zend_Db for a long tine now and I’m happy using it for some of the simpler projects I have had to do. However I have had a requirement to use an ORM.
I was looking forward to using the upcoming Entity component that was being built but after readingĀ this at nabble. I decided that it was time to investigate using Doctrine.
So after having a little play and reading all the tutorials/guides I could find I had a go @ integrating Doctrine into my latest project base.
So far no single guide/tutorial has gotten it 100% right for me. I was wanting to make it a seamless integration using the frameworks application component.
So here goes my amalgamation of quite a few guides to try and give a more complete picture. My apologies if I forget to attribute any bits of code I may have borrowed/adapted. Let me know and I will add you in.
Some things to make you aware of
- First I built this with 1.9.5 of the framework. I havent tried it with any earlier versions but it should work pretty much the same.
- I used Doctrine 1.2. It is still in beta on their website t the time of writing. But having had a nose through their blog I can see that they are on the verge of releasing it as stable. So by the time you read this it will most likely be stable. My reasoning for this is that 1.2 appears to handle the building of models a lot better than earlier versions.
- In order to get all the features I wanted to use working I had to adjust part of the Doctrine library. As part of the way I wanted to use doctrine was to build models automatically from yaml files. Unfortunately Doctrine appears to be reliant upon using a component from the symfony framework. Not that I’m knocking Symfony but I much prefer Zend and as such have no desire to use Symfony. That said.. for the sake of speed I downloaded Symfony and copied the 4 files I needed. I’ll cover what I didĀ bit later. I have logged this as a bug/task on Doctrines bug tracker (http://www.doctrine-project.org/jira/browse/DC-288) hopefully they will spot it and apply a suitable fix/inclusion.
- All my code is part of my own library which called Zucchi. All of my code is available in my project base in my subversion repository here. feel free to make use of it.
First things first…
create your project. I use the tool so my architecturre generally follows this pattern. Once your project is created then we need to install the Doctrine library. I have seen a few different ways to install the library. To minimise the number of include paths I drop the library into my projects library folder. Obvious you may think. Not quite so, a number of guides I read suggested putting the library in its own sub-folder. I decided against this and put it straight into my library folder.
Next I need to build the folders that will contain additional data inside the project. we need to create a folder to contain some doctrine specific data. and a folder to contain our cli scripts. At the end of it we should have the following file structure
project/
application/
configs/
controllers/
doctrine/ # new doctrine folder
data/
fixtures/
sql/
migrations/
schema/
layouts/
models/
views/
bin/ # new folder to contain cli scripts
library/
Doctrine/
Doctrine.php
public/
Quite a few folders there. A lot of guides specify a scripts folder. I use a folder called bin as I tend to store additional binary/cli scripts here historically.
| Print article | This entry was posted by Matt Cockayne on November 26, 2009 at 5:13 pm, and is filed under Spec Ops. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |



about 8 months ago
Great post! I’ve been reading all the same articles that it looks like you’ve already been through. Same result of not a single one having everything right and in one place.
I took a look at the bug that you filed (http://www.doctrine-project.org/jira/browse/DC-288)
Looks like the best solution for now is to register a namespace and add the sfYaml stuff to the autoloader:
$loader = Zend_Loader_Autoloader::getInstance();
$loader->pushAutoloader(array(‘Doctrine’, ‘autoload’), ‘Doctrine’);
$loader->registerNamespace(‘sfYaml’)
->pushAutoloader(array(‘Doctrine’, ‘autoload’), ‘sfYaml’);
This makes my cli task of generate-models-yaml work fine. However, build-all-reload (which is supposed to create the models from the yaml and created the database tables) says that it is creating the database tables, but they don’t actually get created. The DB itself does get dropped and re-created. But after that the tables don’t get created. The models are getting created as expected.
Any ideas as to why the database tables wouldn’t get created? I don’t see any errors that indicate anything is wrong.
Looks like you just created your own task to create the database tables. I was surprised to not see a task already available called “generate-db-yaml”.
about 8 months ago
Hi Jeremy.
Yes I had to create my 0own task to allow table generation. The reason for this was that the default task did not take into account these settings from my ini file
2
3
4
resources.doctrine.generate_models_options.generateBaseClasses = true
resources.doctrine.generate_models_options.classPrefix = "Model_"
resources.doctrine.generate_models_options.baseClassPrefix = "Base_"
because of this it was failing to identify the models correctly and build them accordingly.
I tend to do a lot of my building in separate stages and rarely use the build all taks. In order for the build All to work you would need to create your own version where it calls the newly built task/s instead of the default task.
2
3
4
5
6
7
8
9
10
11
{
parent::__construct($dispatcher);
$this->models = new Doctrine_Task_GenerateModelsYaml($this->dispatcher);
$this->createDb = new Doctrine_Task_CreateDb($this->dispatcher);
$this->tables = new Doctrine_Task_ZucchiCreateTables($this->dispatcher);
$this->requiredArguments = array_merge($this->requiredArguments, $this->models->requiredArguments, $this->createDb->requiredArguments, $this->tables->requiredArguments);
$this->optionalArguments = array_merge($this->optionalArguments, $this->models->optionalArguments, $this->createDb->optionalArguments, $this->tables->optionalArguments);
}
I noticed that they fixed the issue with sfYaml. Its not a perfect solution but it does make it more workable.
about 8 months ago
I failed to mention that the latest 1.2 download of Doctrine includes a vendor folder with sfYaml in it. No more need to manually copy the files over.