My latest Symfony project uses Doctrine as ORM, which is considered to be a lot better than Propel by many people…
Well, not by me. Doctrine seems to have a couple of very good concepts, amongst them built-in validators, a powerful query language, and last but not least, an easy schema language. (Though to be fair, Propel will gain most of these useful things in the future as well or already has, f.e. with its `PropelQuery` feature.)
But Doctrine also fails in many areas; the massive use of overloads everywhere makes it very hard to debug and even worse, it tries to outsmart you (the developer) in many areas, which makes it even more hard to debug stuff which Doctrine doesn’t get right.
A simple example – consider this schema:
Foo:
columns:
id: { type: integer(5), primary: true, autoincrement: true }
name: { type: string }
Bar:
columns:
id: { type: integer(5), primary: true, autoincrement: true }
name: { type: string }
FooBarBaz:
columns:
foo_id: { type: integer(5), primary: true }
bar_id: { type: integer(5), primary: true }
name: { type: string }
(I’ll skip the relation setup here, Doctrine should find them all with an additional `detect_relations: true`)
So what do you expect you see when you call this?
$obj = new FooBarBaz();
print_r($obj->toArray());
Well, I expected to get an empty object, with a `NULL`ed `foo_id` and `bar_id`, but I didn’t! For me `foo_id` was filled with a 1. Wait, where does this come from?
After I digged deep enough in Doctrine_Record, I saw that this was automatically assigned in the constructor, coming from a statically incremented `$_index` variable. I could revert this by using my own constructor and call `assignIdentifier()` like this:
class FooBarBaz extends BaseFooBarBaz
{
public function __construct()
{
parent::__construct();
$this->assignIdentifier(false);
}
}
but now this object could no longer be added to a `Doctrine_Collection` (which is a bummer, because if you want to extend object lists with “default” empty objects, you most likely stumble upon a Doctrine_Collection, which is the default data structure returned for every SQL query).
So you might ask “Why the hell does all this impose a problem for you?”
Well, if you work with the `FooForm` created by the doctrine plugin for you in Symfony and you want to add `FooBarBazForm` via `sfForm::embedFormForEach` a couple of times (similar to the use case described here), you suddenly have the problem that your embedded form for the appended new `FooBarBaz` object “magically” gets a foo_id of a wrong (maybe not existing) `Foo` object and you wonder where the heck this comes from…
I have my lesson learned for the last one and a half days. I promise I’ll never *ever* create a table in Doctrine with a multi-key primary key again and I’m returing back to Propel for my next project.
