php[architect] logo

Want to check out an issue? Sign up to receive a special offer.

First beta of Doctrine 2 released

Posted by on April 28, 2010

The first beta of Doctrine 2, the generic Data Mapper for PHP, has been released today. Doctrine 2 is one of the few object-relational mappers for PHP which implement the Data Mapper pattern instead of the Active Record one; as a result, it is expected to be revolutionary for PHP development as much as Hibernate was for the Java world. For example, Symfony has chosen Doctrine as its default Orm and will follow-up with its second major version, while Zend Framework will provide integration of Doctrine 2 in the form of application resources.

The abstraction of having every object available in memory

The Data Mapper pattern is in general very flexible: you can create domain classes as Plain Old PHP Objects, which do not extend any abstract base class; subsequently a Data Mapper layer abstracts the database as a generic storage. Though, application-specific Data Mappers are generally boring and repetitive to write, while also being prone to errors.

With Doctrine 2, you still produce an object model and, with the aid of mapping metadata in the form of small XML files or annotations, the schema of the related relational database  is inferred, while the client code in the rest of the application lives the illusion of an in-memory object graph.

You can largely ignore the database, considering it an implementation detail. The schema can be generated and created from the command line, and there are more than one thousand unit tests to target the different database management systems used as back ends (MySQL, Postgresql, Oracle, Sqlite) to avoid unpleasant surprises. Depending on your vendor of choice, database-specific SQL code will be generated for the creation phase and during querying.

Underlying technology

Doctrine 2 goes to a great extent to avoid introducing unnecessary code for persistence purposes only. The objects’ content are accessed and reconstituted via reflection, avoiding the use of getters or initialization methods, while part of the object graph can be substituted by lazy-loading proxies which take the place of real objects by dynamically subclassing them; however performance can be problematic if you over use this feature. Moreover, this first beta of Doctrine 2 is the first to support constructors with non-optional arguments; objects are recreated via cloning to bypass the constructor call, further extending the metaphor of objects that never leave memory.

If you have already been using Doctrine 2 in its alpha stage, there is a guide to the upgrade from the alpha 4 version. The official documentation is also fairly good for a project which is not yet officially stable. If you want to contribute to the codebase instead, the development has been moved on github and only a fork divides you from producing a useful patch.

Marco is the keeper of keys and Chief Garbage Collector at Blue Parabola. He can be found on Twitter as @mtabini.


Responses and Pingbacks

Using data mapper rather than active record is pretty much a personal preference, no problem with that.
But what about all people/projects that are currently using Doctrine 1.x? There’s no upgrade path, and Doctrine 1.x loses support pretty soon, why would one want to use Doctrine at all anymore, who knows what happens with Doctrine 3?

Good point Oliver…

Although, I can’t wait for Doctrine 2 to go final 🙂


That’s not a personal choice. It’s an architectural choice, leaded by your project, not by yourself. Probably you never had to deal with complex applications, and only with < 300 tables ones.

The Active Record, Table Data Gateway, Row Data Gateway are good in the situation you do not have to deal with complex logic, mainly because it leads you to duplicated code.
Table Module, which is heavily used by .NET solves this issue by the concept of DataSet and RecordSets that allows you to manipulate collection of objects and inject your complex logic. I agree that Table Module should only be used if you have GUI controls that take advantage directly from these RecordSets.
But considering your Domain Model, PHP and a complex logic, Data Mapper is your best solution.

Anyway, getting back to your feeling about our mindset change.
We'll hold Doctrine 1.X until we feel comfortable to say that PHP 5.3 is heavily adopted. We have the projection that it'll happen in 2011/2012.

This gives you plenny of time to switch. It was a tough decision to us to move from AR to DM. But we think that it's time for PHP developers to learn new things and push the language forward.

For Doctrine 3… we have plans for it, which doesn't mean change from DataMapper to anything else, afaik. But the plan is to leave ORM as our logo and bring Persistence instead. We'll support ODM.


[…] for the Java world. To the point that the PHP open source community is following up by creating Doctrine 2 as an Hibernate for […]

Leave a comment

Use the form below to leave a comment: