Place DQL in front of QueryBuilder again

[wouterj]

A year ago, we decided to move the QueryBuilder section above the DQL section for the following reason:

I tend to use (and recommend) the query builder normally. If we showed that first, the DQL section could then be a bit of an afterthought - like "Oh, and if you want to control things a bit more yourself, you can use this DQL thing".

• @weaverryan

However, I would propose to revert this to DQL before QueryBuilder now. For some reason:

• QueryBuilder adds an abstraction that isn't needed
• Most people are more familair with the DQL (which is almost SQL) syntax than the QueryBuilder API
• As soon as things get more complex than a simple SELECT ... FROM ... WHERE ..., QueryBuilder takes up more lines, has a strange API syntax and isn't easy to follow

On IRC, the first answer when someone asks something about the QueryBuilder is often "try DQL" and in 9 of the 10 cases, it solves the issue. Besides this, once a week someone joins and asks "how can I do this SQL with QueryBuilder?"

I recently had a discussion about when a query builder made sense and it was really hard to find a good situation. In fact, the only thing I can think of is in a case where the query is build dynamically (based on PHP statements) and isn't very complex.

[stof]

The use case for the QueryBuilder is indeed for cases where you need to build the query dynamically (changing conditions based on arguments passed to the function, for instance), for which it becomes easier than heavy string manipulation.

[weaverryan]

👍 for DQL first, followed by "hey, here's a nice object interface for this if you like it!".

The QB has some advantages, but users can easily grow into it if they like.