Glimpse of Doctrine 2.0

Tags: 2.0, custom types, mapping

Posted about 1 year ago by jwage

As you all probably already know, we have been working on Doctrine 2.0 pretty much since before we released Doctrine 1.0. This effort has been primarily led by Roman and he has done an excellent job with things so first a big thanks goes to him.

A few quick facts

  • Doctrine 2.0 will require PHP 5.3
  • Doctrine 2.0 is FAST
  • We will extend the support life of 1.x

We have decided to move forward with Doctrine 2.0 requiring PHP 5.3. This release is a significant one, both for PHP and Doctrine, so we decided to continue support for the 1.x series of Doctrine to give the adoption of PHP 5.3 and Doctrine 2.0 more time.

Hydration Performance

In Doctrine 2.0 the performance when hydrating data is greatly improved. The difference in speed is a combination of code changes and the performance increase from using PHP 5.3.

Version Seconds # Records
1.1 4.3435637950897 5000
2.0 1.4314442552312 5000
2.0 3.4690098762512 10000

A few code snippets

Schema Metadata and Models

In Doctrine 1.1 a Doctrine_Record might look something like the following.

<?php

class User extends Doctrine_Record
{
    public function setTableDefinition()
    {
        $this->hasColumn('id', 'integer', null, array(
          'primary' => true,
          'auto_increment' => true
        ));
        $this->hasColumn('username', 'string', 255);
    }
}

Notice how you have to extend the base class and everything is a public instance. As you probably know this has lots of negative effects as it imposes properties and methods on your models.

In Doctrine 2.0 this limitation was removed and you no longer need to extend a base class.

<?php

/**
 * @DoctrineEntity
 * @DoctrineTable(name="user")
 */
class User
{
    /**
     * @DoctrineId
     * @DoctrineColumn(type="integer")
     * @DoctrineGeneratedValue(strategy="auto")
     */
    public $id;
    /**
     * @DoctrineColumn(type="varchar", length=255)
     */
    public $username;
}

Custom Data Types

In Doctrine 2.0 you can write your own custom data types. Here is an example of what the custom datatype class might look like.

Type Declaration

<?php

namespace My\Project\Types;

use Doctrine\DBAL\Types\Type;
use Doctrine\DBAL\Platforms\AbstractPlatform;

/**
 * My custom datatype.
 */
class MyType extends Type
{
    public function getSqlDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
    {
        // return the SQL used to create your column type. To create a portable column type, use the $platform.
    }

    public function convertToPHPValue($value)
    {
        // This is executed when the value is read from the database. Make your conversions here.
    }

    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        // This is executed when the value is written to the database. Make your conversions here, optionally using the $platform.
    }
}

Adding Custom Type

You can easily register your custom type with Doctrine like this.

<?php

// in bootstrapping code

...

use Doctrine\DBAL\Types\Type;

...

// Register my type
Type::addCustomType('mytype', 'My\Project\Types\MyType');

Using Custom Type

Now in your model definition you can do something like the following.

<?php

namespace My\Project\Model;

/**
 * @DoctrineEntity
 * ...
 */
class MyEntity
{
    /**
     * @DoctrineColumn(type="mytype")
     */
    private $data;

    // ... other properties and code
}

This is only a small glimpse of what is possible in Doctrine 2.0. You will start to see more posts on the blog related to Doctrine 2.0 in the next several months so stay tuned.


Comments (23) [ add comment ]

WoW Posted by Hélder Silva about about 1 year ago.

Oh yes yes yes please :drools:

compatibility Posted by Christof about about 1 year ago.

I wonder how much work it will be to migrate Doctrine 1.x stuff to 2.0. It will probably a while until I have to deal with that, but it would be nice if it wouldn't be a big PITA.

the speed test? Posted by gandalfu about about 1 year ago.

Was it performed with doctrine 1.0 and 1.1 running php 5.3 as well???

@gandalfu Posted by jwage about about 1 year ago.

Yes, all tests were run under 5.3 actually. 1.1 is much faster when used under php 5.3. 20% faster, and 30% less memory.

@Christof Posted by jwage about about 1 year ago.

We will try and document the changes as well as possible to ease the changes for you

php 5.3 Posted by shahin about about 1 year ago.

thanks a lot but if doctrine 2.0 use PHP 5.3 we can`t use it in many shared hosting services and some dedicated hosting too.

but i know PHP 5.3 has very good properties you might use them

@shahin Posted by romanb about about 1 year ago.

Lets see how the world looks in ~6 months ;)

Shared hosting is a different case anyway, if we were to follow the mood and the slowness of shared hosting providers we would still be stuck with php 4.

Great !! Posted by Ace about about 1 year ago.

I love ! Can't wait for a stable version (and hope my hosting provider will quickly upgrade to PHP 5.3).

Did you get inspired by Apache Tapestry 5 ?

metadata Posted by Scott M about about 1 year ago.

the metadata may make your classes look neater, but there must be a performance hit with all the extra parsing involved...

@Scott M Posted by romanb about about 1 year ago.

Sure, but it does not really matter since the result is cached. The way it is implemented it does not even matter whether you use YAML/XML/Annotations/... At the end of the day they're all equally fast.

The metadata of a class is stored in an instance of the ClassMetadata class. And these classes are serializable and can be cached with any of the available caching providers (apc, memcache, ...).

Inheritance Posted by Jorge Pereira about about 1 year ago.

Hi,

With objects inheriting from a base class, it's easy to redefine save() and call parent::save() in order to hook into the saving (or any of the alternatives like preInsert, etc).

How will this work in Doctrine 2.0?

Calling for "DoctrineLight" Posted by Gabber about about 1 year ago.

Calling for "DoctrineLight" ! Much smaller, not all features. A nice light core, that could be equiped with addional modules!

----- Posted by jwage about about 1 year ago.

@Jorge Pereira Events. You will have an EventManager instance and you would pass your value objects to it to save, delete, etc. $user = new User(); $user->username = 'jwage'; $em->save($user);

We will have events placed inside the event manager for preSave(), postSave(), etc.

@Gabber With how Doctrine 2.0 is decoupled in to smaller working pieces you won't be as forced in to things as you are with Doctrine 1.x. So, you can easily only work with a small subset of functionality in Doctrine.

event manager and inheritance Posted by Jorge Pereira about about 1 year ago.

@jwage I see how this will allow Doctrine to be applied on other classes without having to touch their hierarchy, looks sweet.

This also means we'll need to pass around the $em variable or get it using a singleton, and the simplicity of $user->save() is endearing. Will there still be have a Doctrine_Record that uses a singleton event manager? Best of both worlds, and good for code migration.

@Jorege Pereira Posted by jwage about about 1 year ago.

I plan to write some kind of DoctrineActiveRecord extension you can download and make your models extend to get the active record style behavior you're wanting.

--- Posted by Jorge Pereira about about 1 year ago.

@jwage Great. I must say I'm looking forward to playing a bit with this!

@Jorge Pereira Posted by romanb about about 1 year ago.

How you pass around the EntityManager is your choice (or the choice of your framework). You have all the usual options: Pass it around explicitly, put it in a registry, use a DI container. I would not advice wrapping it in a special singleton. If there is a singleton, there should be only 1 singleton, i.e. like a registry.

'Some programmers when faced with a problem think: "I know! I'll use a singleton!" Now they got 2 problems.'

singleton Posted by @romanb about about 1 year ago.

I mostly use Symfony, so I suppose it'll be taken care of by me. ;)

You're right about singleton management, my only point is that if all objects inherit from a Doctrine_Record equivalent, it would obtain the singleton itself.

ooops Posted by Jorge Pereira about about 1 year ago.

Er... the above post is mine, not @romanb's. Sorry.

Entities -- is it meant to do that Posted by Richard about about 1 year ago.

I love being able to use entities in Java and doctrine trying to accomplish what Hibernate does is extremely welcome. But I don't know if I appreciate the attempts in making php doing something it wasn't designed to do, ie using entities in blocked out segments.

Was there no other more php native way to achieve an entities mimic without what appears to be a mere hack? I am sure blocked out segments are to be used for comments??

This little moan aside I am looking forward to using it ! :) Good job guys...

@Richard Posted by romanb about about 1 year ago.

1) docblock annotations are not uncommon and were used in Java also before annotations become a part of the language.

2) docblock annotations are only 1 (of at least 3) ways to do the mapping.

so i'm not sure what you're moaning about ;)

@Richard Posted by Jorge Pereira about about 1 year ago.

Maybe in time annotations will become part of PHP. Although I'm sure that given the current trend for creativity in defining operators and syntax, to use an annotation you'll have to sacrifice your first unborn son, and declare them with

\@\~Annotation~~Value~~ function ...

Lazy Loading Posted by Avi about about 1 year ago.

Just took a look at the trunk of Doctrine. I haven't looked very far, but how are you going to implement lazy loading? It doesn't look like you're using a proxy object?

Create Comment