Doctrine vs Propel

By emiviada in PHP 2 Comments

UPDATE: Here is a great comparison for these ORM’s for the 2.x versions. Thanks to @Pati for sharing the link.

A quick comparison for the most 2 well known and best ORM‘s for PHP.

Here we will try to make a quick comparison about the most known ORM for PHP. To help developers to take the right decision when we need to decide what is the best ORM which could best adapt to our projects.

These 2 more used ORM are as the post title mentioned Doctrine and Propel.

Features

Both ORMs have many similar basic features, they support all the usual operations for CRUD (Create, Retrieve, Update and Delete), from create a new record to update existing ones. Also, both can generate the PHP classes for you, Propel based on XML while Doctrine based on YAML, And another cool feature they have is that both support different database engines (like Mysql, Oracle, MSSQL, etc).

Both support data validation and model relationships. Additionally, they support simple inheritance, although in Doctrine is called concrete inheritance. Doctrine supports 2 types of inheritance: Simple, where all the classes have the same columns, and the Aggregation inheritance, where we store an additional value in the table which allows us the automatic instantiate of the right model type when we make a query.

Well, we saw they almost share the same features so far, but the following are features only Doctrine has.

Behaviors: Doctrine supports many “behaviors” for its models, for instance, a Timestampable model will automatically create two columns: created_at and updated_at, where we can store the creation and update dates.

Searching: Doctrine has a fulltext search engine.

Plus, Doctrine supports data fixtures and migrations, caching, events, pagination, commands line interface and so on, and we can say in advanced features Doctrine has an advantage compared with Propel.

Usability

Documentation

One of the most important thing is documentation of course. Without a good documentation is hard to use any library. Until the last year (2009) the Propel documentation was one of the major problem for them, and it’s true they are improving it there still are work to do. In the other hand, the Doctrine documentation is great and the community is continuously improving it. So, about documentation concern, Doctrine is clearly the winner.

Libraries Use

The first task we have to do with both ORMs is to build the model classes. Doctrine allows us to just write a simple YAML file, or just PHP code if you prefer it. The Propel proposal is to write a XML to define our model classes, and in my personal opinion I prefer to deal with YAML instead of XML, so point for Doctrine :-).

Database operations

The basic operations with CRUD are very similar in both ORMs, however, there is a big different when we need to do more advanced queries.

Propel uses a Criteria/Peer proposal:

1
2
3
4
5
6
<?php
$c = new Criteria();
$c->add(UserPeer::ID, 10);

//SELECT all "User" models which have 10 as their ID and join all foreign tables.
$users = UserPeer::doSelectJoinFoobar($c);

Doctrine proposal is to use Doctrine_Query and a simple customized SQL named DQL (Doctrine Query Languaje):

1
2
3
4
5
6
<?php
$items = Doctrine_Query::create()
    ->from('User u')
    ->leftJoin('u.Foobar')
    ->where('u.id = ?', 10)
    ->execute();

To set values in our model classes these ORMs utilizes different methods: Doctrine uses magic methods, while Propel generates setters and getters. This feature gives to Propel the advantage of autocompletion in most IDEs.

As conclusion I can say that both ORM are great, but I prefer Doctrine. And, of course, you can put the ‘My opinion’ label to this post.

And in this link you can find a comparison that Symfony made between these 2 ORMs.

What is new in Symfony 1.3 / 1.4

By emiviada in Symfony 1.x 3 Comments

At the end of this month it goes out the last release of Symfony and here we will review what are the new news. If you have already used 1.2 version you will notice a couple of improvements have been added.

Between the new functionalities, the most highlighted are:

Mailer

Symfony 1.3/1.4 comes with a new integrated mailer based on SwiftMailer 4.1. And, to send an email is as easy as we show below using the composeAndSend() method:

1
2
3
4
5
6
<?php
public function executeSendEmail()
{
    $this->getMailer()->composeAndSend('from@example.com', 'to@example.com', 'Subject', 'Body');
}
?>

If you need more flexibility and you need to attach a file, you can use the compose() method and then send it:

1
2
3
4
5
6
7
8
9
10
<?php
public function executeSendEmail()
{
    $message = $this->getMailer()
        ->compose('from@example.com', 'to@example.com', 'Subject', 'Body')
        ->attach(Swift_Attachment::fromPath('/path/to/a/file.zip'));
   
    $this->getMailer()->send($message);
}
?>

Swift Mailer is a great and powerful library, and if you want to know more about it you can check its documentation.

Security

In these versions when you use the generate:app command, the security is already actived by default. The escaping_strategy value is already activated by default, but you can deactivate it with the –escaping-strategy option. Also, for the csrf_secret option, the framework already comes with a random generated keyword and you can change it in the setting.yml configuration file.

Widgets

– Labels by default: When a label is auto-generated from the field name, the label is defined without the _id suffix (if it has it). For instance, for the client_id field name, the generated label will be ‘client’ now (it was client_id before).

– sfWidgetFormInputText: Now the sfWidgetFormInput class is abstract, and the text input fields should be created with sfWidgetFormInputText.

Forms

– sfForm::useFileds(): This new method remove all the form fields, except those passed as argument. This ease the fields visualization in the form view without the need of make an unset() of the unwanted fields. For instance, when we add a new field in the base form, this one do not appear automatically in the form view at least we add it explicitly as an argument of this method:

1
2
3
4
5
6
7
8
9
<?php
class ArticleForm extends BaseArticleForm
{
    public function configure()
    {
        $this->useFields(array('title', 'content'));
    }
}
?>

By default, the array is used to change the fields order; we can pass a second argument as a false value to deactivate this automatic sort.

– sfForm::getEmbeddedForm($name): Now we can access a particular embedded form using the getEmbeddedForm() method.

Autoloaders

All the Symfony’s autoloaders are case-insensitive now, since PHP is case-insensitive as well.

Default ORM

Symfony 1.3/1.4 comes with Doctrine as its default ORM.
If we want to use Propel as ORM, we should use the –orm=Propel option:

1
:$ php symfony generate:project foo --orm=Propel

And if we want to do not use Doctrine neither Propel, we can use the –orm=none option:

1
:$ php symfony generate:project foo --orm=none

These are the most highlighted features to me :D. There are a lot more improvements related to widgets, validators, routing, and much more CLI task as well.