PHP 5.3 and Doctrine 2.0 Teaser

Tags: 2.0, teaser, php 5.3

Posted over 3 years ago by jwage

We've been really busy around here as you may have noticed. Doctrine 1.1 is about to be released, we just got some much needed new documentation, we're going to be offering a printed version of the documentation soon! Something we haven't talked to much about is Doctrine 2.0! Roman has been quietly working on the next major major version of Doctrine, 2.0. This version will be taking a big leap by requiring PHP 5.3! The progress this new version of PHP is so great and it lends itself very well to the world of Object Relational Mappers.

Doctrine 2.0 Teaser

Here is an early teaser of what one of the class meta data drivers looks like:

<?php

namespace Doctrine\Tests\Models\CMS;

/**
* @DoctrineEntity(tableName="cms_articles")
*/
class CmsArticle
{
   /**
    * @DoctrineId
    * @DoctrineColumn(type="integer")
    * @DoctrineIdGenerator("auto")
    */
   public $id;

   /**
    * @DoctrineColumn(type="varchar", length=255)
    */
   public $topic;

   /**
    * @DoctrineColumn(type="varchar")
    */
   public $text;

   /**
    * @DoctrineManyToOne(targetEntity="Doctrine\Tests\Models\CMS\CmsUser",
           joinColumns={"user_id" = "id"})
    */
   public $user;

   /**
    * @DoctrineOneToMany(targetEntity="Doctrine\Tests\Models\CMS\CmsComment", mappedBy="article")
    */
   public $comments;
}

Notice these few things:

1.) We define the class meta data for the model in the doc block. This is just one way you will be able to define class meta data. YAML schema syntax will be possible as well.

2.) The CmsArticle class is not extending anything! Thats right in Doctrine 2.0 your domain model won't be imposed on one bit!

3.) The properties on the class are not required to be public, they can of course be private or protected. Doctrine will not require you to have a getter and setter methods for every property. It is totally up to how the user wants to design the class.

Doctrine 2.0 is being built around the concept of a UnitOfWork that keeps track of your objects during a script execution. You just work with your objects normally and when you commit a UnitOfWork, Doctrine takes care of synchronizing your mapped objects with the database, taking care of referential integrity etc. The boundaries of a UnitOfWork can be defined by the user, typically, however, one script execution requires only one UnitOfWork. In Doctrine 2.0 we really try to keep Doctrine out of your domain objects as much as possible, yet providing you with all the features you need.

PHP 5.3 Benchmarks

While I have been playing with Doctrine 2.0 I did some simple benchmarks against the Doctrine 1.0 version test suite to see what kind of performance improvements were made. I was pretty impressed!

These tests are not the best obviously but it does clearly show that when you run the Doctrine tests under PHP 5.3, it is faster and uses less memory.

PHP 5.2.8

# Seconds Memory
1 24 129170.648438 KB
2 23 129164.078125 KB
3 23 129176.851562 KB

PHP 5.3.0alpha4-dev

# Seconds Memory
1 21 89858.7421875 KB
2 20 89864.59765625 KB
3 21 89867.89453125 KB

The Doctrine test suite uses 31% less memory and is 17% faster when running under PHP 5.3!


Comments (14) [ add comment ]

Great work Posted by Ross about over 3 years ago.

Great work, this looks like it's going to be an interesting release :)

popo Posted by lucas about over 3 years ago.

jwage, this is quite impressive and each more like hibernate ;-)

orm with Php Plain Objects and using docblock to describe model.

awesome.

Glad to See Annotations Posted by Kris Jordan about over 3 years ago.

Glad to see Doctrine will make use of annotations within the DocComment block. This is a technique we've been using extensively in the ORM and Controllers of the Recess Framework (http://www.recessframework.org/). We haven't begun porting to 5.3 yet, but even in 5.2.x annotations have been really handy to have.

Looks like you're going to inherit the xdoclet/Java-syntax for annotations. We ultimately chose not to use this syntax opting for a simpler one which transforms directly into keyed PHP arrays and to use a bang ! instead of an @ sign to avoid conflicting with doc file generators.

Either way, I believe using doccomments as a means to provide metadata about PHP classes is the way to go. Continually impressed with your work and look forward to seeing how you take advantage of 5.3's advances internally.

outlet ? Posted by desfrenes about over 3 years ago.

This looks like Outlet ORM (http://www.outlet-orm.org)... but Outlet ORM has no annotations, only entity/property/relationships mappings in the form of configuration arrays (http://www.outlet-orm.org/manual/ch04.html).

I find it more handy to have annotations since it allows to keep everything in one place. Also, it looks a bit like ezpdo (http://www.ezpdo.net/blog/?p=5#the_data_model)

JPA Posted by romanb about over 3 years ago.

Doctrine 2 is much more involved than Outlet or EZPDO. These are not projects we look at, for Doctrine 2 we're mainly looking at JPA (which I use on a daily basis).

Metadata Posted by romanb about over 3 years ago.

Also, note that docblock annotations will be just one way to define the mapping. There will be at least also the option to specify all the mapping in YAML and if someone wants to write a driver for it, even XML or whatever.

Metadata Posted by romanb about over 3 years ago.

Also, note that docblock annotations will be just one way to define the mapping. There will be at least also the option to specify all the mapping in YAML and if someone wants to write a driver for it, even XML or whatever.

Annotations Posted by mremolt about over 3 years ago.

It seems, a lot of very current PHP projects start to use annotations. Another example is the upcoming flow3 framework.

For example, the aspect oriented features make heavy use of annotations (and namespaces all over the place of course):

http://flow3.typo3.org/documentation/reference/aop-framework/

I'm starting to spot a trend here, although I might be wrong, because both projects are heavily Java inspired (Spring framework for flow3). So other developers without this background might see this differently.

ORM Posted by matze123 about over 3 years ago.

(POJO) POPO ?-) (funny in german)
really great i use symfony 1.2 with doctrine and i have played with the idea to use outlet, now i read it comes with doctrine 2

my experinences with doctr. 1.0 in symfony 1.2 : it's easy and transparently to work with - better than propels special syntax (thanks)

with 2.0 we can easier print it out (print_r) and better work with inheritance and persistence - nice

about annotations : i think it's an aberration, because it's a language in another language, the wishes are growing and the syntax will be more complex, where is the end (maybe as a meta step ? )

my wishes for 2.0 : - no virtual functions (IDE) - one default syntax : camelcase ( no virtual getter functions with regexp/camelcase/underline test of name)

greets matze

Download? Posted by Fallen][Angel about over 3 years ago.

Hello guys,

a little question: I work at little project (Only private, non-professional) with PHP 5.3. Alpha and the new namespaces. Exist a link to download the new doctrine 2.0 (alpha is also okay)? So I can start directly with the new doctrine!

alpha Posted by romanb about over 3 years ago.

Doctrine 2 is not in Alpha yet. This will be announced here once this happens.

OS Posted by Henrik about over 2 years ago.

IMO since Doctrine is Opensource the development should be done in a public read respotori :)

@Henrik Posted by romanb about over 2 years ago.

I dont understand. What is not public about trunk?

Zend Encoded Posted by Fordnox about over 2 years ago.

"Notice these few things: 1.) We define the class meta data for the model in the doc block. "

Will that work with Zend Encoded files ?

Create Comment