mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Setting to disable DQL parsing errors #6348
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @oojacoboo on GitHub (Nov 25, 2019).
Originally assigned to: @Ocramius on GitHub.
Feature Request
Summary
Currently the DQL parser, via the Lexer, is checking to ensure that all syntax is compatible with all database platforms. The result of this is very limiting and requires that developers implement work arounds to enable custom database functions, or functions not supported by all.
This feature only has value for developers that are trying to write apps that need to be compatible with multiple database engines. That's a small fraction of the developers using Doctrine.
I'm suggesting that Doctrine should not throw exceptions when a function, in particular, isn't found in the Lexer and instead should just let PDO blow up, even possibly catching the PDO exception, should some cleanup being required. So, basically adding a setting that removes these checks to allow developers to write their queries as they wish.
@lcobucci commented on GitHub (Nov 26, 2019):
DQL isn't SQL and has its own syntax. The ORM is a generic abstraction layer and as such imposes its constraints. People are completely free to use SQL via the native query API if/when they need or extend the DQL with custom functions for their app-specific needs.
Dropping the DQL syntax validation is a no-go for me.
@oojacoboo commented on GitHub (Nov 26, 2019):
@lcobucci I guess you'd just choose to leave it enabled then, via the setting.
@Ocramius commented on GitHub (Nov 26, 2019):
DQL has its own semantics that are required to be validated, since it is logically different from SQL.
It has to be parsed, interpreted, transformed into a resultsetmapping, and it has to be comprehensible by DQL/SQL walkers in all of its AST in-memory representation.
It is fundamentally its own language, and if SQL is what is needed to get something specific to a certain DB to run (for example via recursive queries, stored functions), then SQL should be used, instead of hoping to make DQL more SQL-ish.