My biased view on Doctrine vs Propel

I’m getting old and I’m old fashioned.

I’m still using mysql, not mongoDB.

I’m using php and apache, not node.js, ruby, python or lighttpd, nginx or ….

And I’m using propel again (1.5), not doctrine. AND I’M LOVING IT!!

After #sfdaycng 2009, the presentations and talks there, I forced myself to giving Doctrine a try and really liked it then. A lot of reading through documentation in the beginning if you are new to it, but hey, that’s normal. However, today, even when writing a simple query, I still have to consult the docs. Why? The syntax seems not to be “my style” somehow, it won’t fit into my type of writing code.

But there is such a HUGE difference between Doctrine and Propel and Doctrine is SO MUCH BETTER

Is it? Do I care what’s inside if I’m only querying a database without using all possibilities? Remember sfLive 2010?

“Is Doctrine re-inventing propel” Hahaha LOL ROFL LMAO

At this years big symfony conference #sflive2010, in a Q&A session about Doctrine2, a poor guy obviously asked the question, that made it into a big running gag: “Are you trying to re-invent propel?”

I have to admit and regret that I was not there, but if you followed the #sflive2010 hashtag on twitter, it was not very long until this got tweeted over and over again. And everybody was making fun of it…

Sure, it is kind of funny to ask @jwage, (lead) developer of Doctrine that question… But hey? What’s really so funny about it?

While everybody in the audience laughed, it really would have been interesting to

a) see how many were trying to smirk, wondering whats so funny about that

b) know how many would have been able to give a good reply on that?

And with “good reply” I mean, explain the difference.

And with “difference” I mean, explain it beyond

  • “doctrine has the schema.yml and the model classes in a subfolder”
  • “propel uses two classes User and UserPeer, doctrine has User and UserTable”
  • “propel has a criteria object, doctrine a query object”

If you started with symfony 1.0 as a developer that did not work with frameworks like symfony before (like I did), everthing is “symfony” – may it be propel, phing, creole, PDO, … and getting into these differences was not really worth it in the first place if you wanted to get started with writing your first applications.

What I’m trying to say: I guess that a lot of symfony developers out there don’t know or care about “Doctrine” vs “Propel” – they use the default. And they call it “symfony”, thinking that it belongs to it. If they started with symfony <1.2, they’ll use propel, now they use doctrine – because it’s the default. You learn it, you use it, you stick to it.

And I sticked to propel throughout 1.2. And it was quite save for me getting along ignoring Doctrine. Just then, when I started using Doctrine after #sfdaycgn I found new things, new approaches, things I liked, things I had to learn and a lot of stuff I could not get the hang of.

So now, with propel 1.5 and the new Query objects, I gave it a try and was so excited, I decided to come back to Propel. Just because it “feels like home” and fits my personal style of thinking/coding.

And of course both ORMs have their features and behaviours and at #sfdaycng Doctrine had more of them and so on… But I also assume that a lot of those features are beyond most everyday developer’s needs

But Propel is dead

Oh no, it’s not!!!

With the new 1.5 it REALLY got amazingly easy to write your code, extend your Query Model and easy query creation. 1.6 is on it’s way and 2.0 was just recently announced to be based on Doctrine2, as a layer on top, providing the usability features… that’s something we will have to wait for, but I does sound very good.

But Benchmarks show that…

So what? I couldn’t care less. Why should I? I am not running sites that have gazillions of users with quadrubillions of tables and hexafoobarillions of rows – I don’t care if grabbing all posts with a certain topic and tag for a given user takes 111 ms or 132 ms. But I do care if I have to consult the docs for writing that query because I couldn’t remember the syntax or – on the other hand – my IDE (yeah, right, eclipse, I’m REALLY old fashioned) nearly automagically creates the query for me.

But what are you actually trying to say?

  • Most developers don’t need benchmarks to find their ORM – it’s about own style and preference (or customer specs, but thats another story)
  • Some symfony developers might not even have thought about giving “the other one” a try.
  • Personally, I get along with propel 1.5 better
  • I’m getting old

So, if you know Doctrine, give Propel 1.5 a try.

If you only use Propel, give Doctrine a try.

And if you still use Propel 1.4 – MAN!!! Get the 1.5!!!

Any comments appreciated, I really like to see what I’m missing

PS: I’m even more old fashioned: I’m using vi – not vim, but eclipse with the vi plugin. Why? REAL code completion! A wonderful thing with propel 1.5!

How to configure symfony unit tests to use an sqlite memory database

Since Bernard Schussecks presentation at “symfony Day Cologne”, talking about lime and using sqlite memory tables for unit tests, I was wondering HOW TO DO IT

Well, there was not much talk about the how… of course this must be known to everybody – such an easy task. (Find yourself some <irony> tags to put around this).

Well, at least I did not have a clue how to do it and did not find too much information on it in the web…

So, spending some more time with testing and some rare tutorials on it, I finally made it work!!

And for you and me and everybod else, I’ll note it down for reference…

Assumptions/Prerequisits:

  • We are using symfony and doctrine
  • In test/fixtures we have a/some yml files with test data

First, we need to set up the test connection to use sqlite:MEMORY:

In your config/database.yml add

test:
  sqlitetest:
    class: sfDoctrineDatabase
    param:
      classname: DebugPDO
      dsn: 'sqlite::memory:'

(yes, ::)

Now, lets assume (accoding to the Jobeet tutorial Day 8 ) we have a

test/bootstrap/Doctrine.php

Now, the important part is to not only LOAD the data but first create the tables:

  include(dirname(__FILE__).'/unit.php');
  $configuration = ProjectConfiguration::getApplicationConfiguration( 'frontend', 'test', true);
  new sfDatabaseManager($configuration);
  Doctrine::createTablesFromModels(dirname(__FILE__).'/../../lib/model');
  Doctrine::loadData(sfConfig::get('sf_test_dir').'/fixtures');

Now, in our test files we can simply call

include(dirname(__FILE__).'/../../bootstrap/Doctrine.php');
$t = new lime_test(4);  //change it with the number of tests you have 

everytime
Took me quite some time to figure it out – really simpe – if you know how…

Der Umstellerei nicht genug…

Posted on 2009-11-24

Von symfony 1.0 über 1.1 zu 1.2 zu 1.4 und von propel zu doctrine und von prototype zu jquery

Das ist das, was ich gerade mit meinem Karopier-Code mache. Und irgendwie hab ich das Gefühl, dass kann nicht ewig so weitergehen. Kaum hab ich was fertig, kommt was neues und ich will’s einbauen/anpassen…

Aber ich glaube, mit symfony 1.4 (stable ist ja um die Ecke), doctrine und jquery hab ich jetzt etwas, das länger halten sollte. Von daher machen die Umstellungen jetzt, so früh, glaube ich sogar noch Sinn, auch wenn ich jetzt ein paar Sachen wieder neu machen muss, die vorher schon taten…

Nächster Plan: Karo2.0 auf Doctrine

Posted on 2009-09-25

So, der Plan für die nächste Zeit lautet:

Alles, was ich bisher in Karo2.0 gemacht habe, auf Doctrine umzubauen. Warum? Ganz einfach: Ich will ordentliche Unit Tests machen, um mit den ganzen Funktionen (insbesondere denen zum “aufräumen”) sicher zu sein. Und das macht sich am besten, wenn man nicht die “echte” sondern eine Testdatenbank benutzt.

Und da propel das nicht so gut drauf hat, mehrere Datenbanken gleichzeitig zu bedienen… werde ich wohl doch jetzt auf Doctrine umstellen – und somit nochmal “fast from scratch” neu anfanfen – aber diesmal dabei gleich die Tests schreiben.

Krasses Unterfangen, aber wir schon irgendwie gehen.

Von daher: Heut kommt der große Moment, wo ich mit die “original”-DB nochmal runterziehe und mir daraus dann ein schema erstellen lasse. So der Plan – mal schauen, wie weit ich komme, bis ich verzeifle…

Move from Propel to doctrine

Original Date: 2009-09-11

Big day today!

My plan is to dive into doctrine today by converting a small application. I have been using propel all the time and now it looks like I need to change something, because doctrine will be the path forward for symfony.

BTW, I’ll write this one in English, because it might help some people out there (and not only Germans…)

So, first stop:

The symfony and Doctrine Book

http://www.symfony-project.org/doctrine/1_2/en/

So I ran

./symfony configure:database --name=doctrine --class=sfDoctrineDatabase "mysql:host=localhost;dbname=dbname" user secret

to get the basic connection set up. Afterwards, I needed to clean some old Propel line removed from the database.yml

My Database is alread existing, so I can recreate the schema from the DB.

php symfony doctrine:build-schema

et voilà – I have a subfolder doctrine with the schema.yml

Hmm, first question now: Where did the _attribute: { phpname: .. } go?

Looking at the schema, the big difference between propel and doctrine seems to be: doctrine specifies a tablename for a parent element called like the table, but propel specifies a phpname for a parent that IS the table…

In my example I have a mysql table called “plz” but the phpname was “Zip”.

So, doctrine created a classname “Plz:” with tableName: plz – I try to change “Plz:” into “Zip:” … keep your fingers crossed

The doc talks about multiple connectiosn and attributes now, I’ll skip that for now, got no clue what the attributes mean and I only need one connection.

BUILD!! Thats what I want to do!!!

I don’t want to erase the table, so I only

php symfony doctrine:build-model

and YES, as hoped, it created a “Zip.class.php”. COOL!

add some

php symfony doctrine:build-forms
php symfony doctrine:build-filters
php symfony doctrine:build-sql

and now we should be fine, right?