Update documentation to recommend DQL over QueryBuilder when possible #7880
Conversation
1f8b787 to
7dd506c
Compare
7dd506c to
9d07080
Compare
9d07080 to
d1db065
Compare
|
LGTM, good work, @kuraobi! |
|
|
||
| But the ``QueryBuilder`` is not an alternative to DQL, it actually generates DQL | ||
| queries at runtime, which are then interpreted by Doctrine. This means that | ||
| using the ``QueryBuilder`` to build and run a query is actually always slower |
There was a problem hiding this comment.
While I understand you want to convince people to not use QueryBuilder, using performance as a reason sounds funny in the context of an ORM. A few method calls is totally negligible and not measurable.
There was a problem hiding this comment.
Totally, but I think some people might be using the QB because they think it's more performant.
There was a problem hiding this comment.
That paragraph was my idea, but I'll make a PR to amend it if more people think it's irrelevant. I I still like it because it teaches people about the internals.
There was a problem hiding this comment.
The point here is to explain that the QB is an extra layer that comes at a cost. Coding choices are based on trade offs, and I'm just emphasizing that performance wouldn't be in the "+" column. A lot of people think the QB is preferable because Doctrine doesn't need to parse DQL, but it's not true.
Fixes #7520
As explained in the related issue, the idea here is to promote usage of DQL over
QueryBuilderwhen writing static queries. While theQueryBuilderhelps dynamically building DQL, it brings complexity to the code, so it should only be used when it actually brings value compared to DQL.While the
QueryBuildercould be argued to bring abstraction, the real abstraction is DQL itself, and theQueryBuilderdoes not bring more abstraction to writing queries.I tried to clarify the intent of both DQL and the
QueryBuilder, so please tell me if you think my update is clear enough or not, and I'll update the PR accordingly.