Has anyone used Doctrine?

sneakyimp

A co-worker has suggested that we use Doctrine, specifically an object-relational mapper (ORM), on a new project we are starting. As far as I can tell, it's poorly documented, requires one to learn DQL, YAML, and its own poorly commented API, and will introduce some fairly heavy OOP layers into my application. I can appreciate that it would be handy to have auto-generated convenience functions for INSERT/UPDATE/DELETE but I don't see any particular advantage beyond that.

Has anyone used it? Has anyone heard of it? Does anyone have an opinion about ORMs?

bradgrafelman

I've had some run-ins with Hibernate in the Java world.

Maybe it's just me, but I hated it with a passion. I gave up trying to figure out why ORMs are useful and simply wrote the SQL queries myself (I'd much rather stare at my 35+ line SQL query than try to figure out how the hell Hibernate wanted me to use its objects and whatnot).

sneakyimp

I asked my coworker WHY and he said that it allows one to write OOP code instead of queries (this looks nightmarish to me) and it makes one's application more db agnostic thanks to hefty database abstraction layer.

I'm thinking that PDO probably provides sufficient database abstraction to keep one's application agnostic and furthermore it's more likely that one would need to support db clustering than a switch to an entirely different DBMS.

I dunno. I'd like to hear why people like Hibernate so much.

laserlight

I think that these tools are a matter of "Your Mileage May Vary". I am pretty happy using Django's ORM at work because I like the abstraction that it provides, though in some cases the law of leaky abstraction rears its ugly head and I have to delve into SQL. Consider that "nightmarish" example:

SELECT u FROM User u WHERE u.id = ? OR u.nickname LIKE ? ORDER BY u.surname DESC;

I suspect that "SELECT u" should be "SELECT *". Anyway, let's proceed to look at their example code:

$qb->add('select', $qb->expr()->select('u'))
   ->add('from', $qb->expr()->from('User', 'u'))
   ->add('where', $qb->expr()->orx(
       $qb->expr()->eq('u.id', '?1'),
       $qb->expr()->like('u.nickname', '?2')
   ))
   ->add('orderBy', $qb->expr()->orderBy('u.surname', 'ASC'));

Can you spot the bug? Yes, the 'ASC' should be 'DESC'. Now, in Django's ORM, given id and nickname variables, I might write this line of Python:

User.objects.filter(Q(id=id) | Q(nickname__contains=nickname)).order_by('-surname')

The '-' in '-surname' concisely indicates to order in reverse, but it could well be more difficult to spot than 'ASC' versus 'DESC'. Yet the conciseness is somewhat of an illusion as the code is comparable to the SQL. What's more fun for me is to work with a queryset of User objects, i.e., to think at a higher level of abstraction than rows in the database.

sneakyimp

Good lord. The OOP code is about 281 chars and the original query is about 81. Granted, one would hopefully benefit from some kind of code hinting or autocomplete. It's still a LOT more code. I'm not sure what part of this kind of thing you might call fun, but I'm not the judgmental type. I personally would hate to see what it looks like when you have a lot of inner joins combined with left joins and also a nest of ANDs and ORs. And what about aggregate functions like SUM, MAX, LEN?

Your leaky abstraction article was a good read. And your Django python looks really terse.

So far the score goes something like this for Doctrine
PROS
More complete database abstraction
More "fun" to deal with OOP rather than database objects or queries
CONS
Still requires knowledge of RAW SQL
Learning curve for ORM classes and usage
Learning curve for DQL and YAML
Other leaky abstraction losses?

laserlight

sneakyimp wrote:
The OOP code is about 281 chars and the original query is about 81.

To be fair the only thing OOP about that example is that some Expr class was used. The example is basically about a query builder (i.e., that constructs an SQL statement from component parts), not really about an ORM (i.e., that relates objects in the domain model to the database). If you needed to construct the query dynamically yourself, you would also have quite some extra PHP code.

Now, looking further into Doctrine, I see that your example does not actually contrast creating a query in Doctrine with SQL. I stated that "SELECT u" should be "SELECT *", but that's wrong. You're looking at Doctrine Query Language, not SQL, so the example is just a toy to help explain the query builder. My guess is that you don't need this verbose query builder at all, unless you really need to construct the query dynamically. You could have used DQL directly (or perhaps methods on your Doctrine entity objects) and still obtain the benefit of database abstraction.

sneakyimp

The example was shown to me when I said "how do you construct a join". I've been too busy setting up the server to truly get my feet wet so I don't know if there's a simpler way. I consider the documentation pretty poor in that I have not been able to determine by reading/searching it how to perform a join.

Having seen things like SimpleDB which doesn't even support JOINs, I'm wondering if maybe there's some magic world of the future that doesn't require them. In the meantime, ORM is just kind of making me sad. I feel like I should know it but it just looks painful -- at least Doctrine does.

I wonder how popular it is. I know that Hibernate is quite popular, having heard of it many times.