One of the DQL parser authors here. Comments inline.
On Wed, Jul 22, 2020 at 12:43 PM Cerulean <ceru...@gmail.com
> Hello everyone,
> I'm new to learning Doctrine, and so far it's been really great! I love how easy it is to work with entities and have Doctrine map table data to php classes. I'm looking forward to learning more and seeing how Doctrine can improve my productivity. That said, there has been one really noticeable pain point: DQL error messages. When everything works correctly DQL is nice and convenient. But when DQL fails (or rather when I fail at writing DQL) the error messages are terrible.
> For really obvious mistakes, like when I'm accidentally missing a keyword like WHERE or FROM, the error message is basically useless. Sure I see ->syntaxError('end of string') in the exception trace, but there's no information regarding the location of the error. Where exactly is the unexpected end of the string?
You actually have the column information in this scenario. Assuming:
SELECT s.wrong FROM Submission s s.wrong = :check (missing where here)
Look at the source code:
It should trigger a QueryException to you something like: [Syntax
Error] line 0, col 34: Error: Expected end of string, got 's'.
The specific place where you got this in your stack trace is:
> For non-obvious mistakes, where the DQL syntax is correct, but there's a problem with what I'm asking Doctrine to do, the error messages improve, but they are still poor. I might see something like semanticalError('line 0, col 61...') that at least gives me an idea as to the location of the problem. But it would be much better if the error included the problematic detail directly. Consider the dead simple example "SELECT s.wrong FROM Submission s", where the "wrong" property doesn't exist for the Submission entity. Why can't DQL quote that "s.wrong" is the unknown path expression (or that "wrong" is the unknown property?) instead of making me interpret Doctrine parser backtraces and look up character offsets?
Now this gets interesting.
Let's talk about Parsers. The previous item you mentioned is what we
call as a syntax error. Correlating this to a language, like English,
is the same as you formulating a sentence without a verb. These errors
are easy to catch when implementing a DSL parser.
The error you just mentioned, "s.wrong" is the unknown path expression
because wrong is an unknown property, let's review the query from a
Analize tokens in this order:
Can you tell me what "s" and "wrong" are? Is "s" valid? Is "wrong"
valid? Is "wrong" within the context of "s" valid?
Well, that's when it enters semantical errors. There are several ways
to do it. We did NONE of them, but mixed a few different ways
In Compiler's theory, you were supposed to create stubs for parsing,
and then do a second pass verifying, once all the "code" is
syntactically verified. This means we'd have to parse the DQL twice.
Well, that is a waste of time in an interpreted language like PHP,
right? Exactly... so we cheated. We effectively create the proper
values, but we also schedule them for validation once the "code" is
completed. Verification happens as part of "processDeferred*" methods.
So, what does that do? It makes sure all the "s"s and "wrong"s are validated.
Getting back to your question: Why can't DQL quote that "s.wrong" is
the unknown path expression (or that "wrong" is the unknown property?)
instead of making me interpret Doctrine parser backtraces and look up
It does, and the specific method that verifies this is here:
Reporting of the error happens through this method:
Your QueryException would be something like: [Semantical error] line
0, col 61 near 's.wrong FROM': Error: Class Submission has no field or
association named 'wrong'.
> Those are all simple examples. Right now I'm trying to get a LEFT JOIN working and I have no idea what I'm doing wrong. I'm certain that it's my fault (working with databases isn't my regular job) but the DQL error messages sure aren't helping. It's quoting me a line/col number that puts the error inside the JOIN keyword; the "col" index is literally between the "I" and "N" characters! I expect this is due to the fact that my DQL string is multi-line. I assume my string is collapsed to a single line before execution, since the error location is always "line 0". Most likely Doctrine did not adjust its character index to account for the removed newlines. I can take that into account manually when I count characters, but this is just another example of poor error reporting wasting my time. I can give many more examples, and I've only recently started using DQL.
> As I mentioned earlier, working with databases isn't what I do most of the time. But when I've worked with regular SQL the error messages were pretty good at helping me figure out what I did wrong. An SQL error like "unknown column 'wrong'" points you right to your mistake. I'd love to see Doctrine do the same. I think this would go a long way towards making Doctrine more usable and friendly.
> I don't know if this is the best venue for this feedback. If there's a better way to communicate this issue to the Doctrine team please let me know. I just want to see the project improved, because so far I see that it's a very nice tool with a lot of benefits.
We're always open for contributions! The pointers I gave are the
actual code it runs to show you these messages.
I do feel however that something in your application is swallowing the
actual exception, and you only have visibility to the stack trace.
My recommendation is to traverse through your code and make sure the
errors are actually not being swallowed, and then proceed to looking
into the Parser class for a contribution! =)
> Thanks for listening!
> You received this message because you are subscribed to the Google Groups "doctrine-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to doctrine-use...@googlegroups.com
> To view this discussion on the web visit https://groups.google.com/d/msgid/doctrine-user/4fa5e98a-1247-47b4-8acb-d5012a97ae91o%40googlegroups.com
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599